最近重读了一遍《代码整洁之道》，这本书既是整洁代码的定义，也是写出整洁代码的指南。我认为既适合新手阅读，快速提升代码质量；也适合老鸟阅读，持续精进。本篇将汇总《代码整洁之道》的必读要点，把书读薄，方便各位快速阅读。
第一，是个程序员；第二，想成为更好的程序员。
有多少程序员，就有多少对整洁代码的定义。就像武术家一样，有不同的流派，代码整洁也有不同的思想流派。鲍勃大叔是 「对象导师整洁代码派」的，《代码整洁之道》一书传授正是这一流派的思想和方法。
每个系统都是使用某种领域特定语言搭建，而这种语言是程序员设计来描述那个系统的。函数是语言的动词，类是名词。编程艺术是且一直就是语言设计的艺术。
大师级程序员把系统当作故事来讲，而不是当作程序来写。他们使用选定编程语言提供的工具构建一种更为丰富且更具表达力的语言，用来讲那个故事。
写函数需要干净利落，这样可以形成一种精确而清晰的语言，帮助讲故事。
什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。
好注释与坏注释：
| 好注释 | 坏注释 |
|---|---|
| 1 法律信息 2 提供信息的注释 3 对意图的解释” 4 阐释 5 警示 6 TODO注释 7 放大 8 公共API中的Javadoc |
1 喃喃自语 2 多余的注释 3 误导性注释 4 循规式注释 5 日志式注释 6 废话注释 7 可怕的废话 8 能用函数或变量时就别用注释 9 位置标记 10 括号后面的注释 11 归属与署名 12 注释掉的代码 13 HTML注释 14 非本地信息 15 信息过多 16 不明显的联系 17 函数头 18 非公共代码中的Javadoc |
代码格式不可忽略。代码格式关乎沟通，而沟通是专业开发者的头等大事。
一行代码应该有多宽？
应该遵循无需拖动滚动条到右边的原则。鲍勃大叔认为这个上限是120个字符。
每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。
将变量设置为私有（private）有一个理由：我们不想其他人依赖这些变量。
数据、对象的反对称性
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。
面向对象代码便于在不改动既有函数的前提下添加新类。
所以，对于面向对象较难的事，对于过程式代码却较容易，反之亦然！
得墨忒耳律认为，模块不应了解它所操作对象的内部情形。
数据传送对象：
最为精练的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或DTO（Data Transfer Objects）。DTO是非常有用的结构，尤其是在与数据库通信、或解析套接字传递的消息之类场景中。
对象曝露行为，隐藏数据。数据结构曝露数据，没有明显的行为。
编写既整洁又强固的代码——雅致地处理错误代码的一些技巧和思路。
整洁代码是可读的，但也要强固。可读与强固并不冲突。如果将错误处理隔离看待，独立于主要逻辑之外，就能写出强固而整洁的代码。做到这一步，我们就能单独处理它，也极大地提升了代码的可维护性。
如何将外来代码干净整合进自己的代码？这其实就是边界的问题，边界上的代码需要清晰的分割和测试。
整洁的测试有什么要素？有三个要素：可读性，可读性和可读性。
每个测试函数只测试其中一个概念。每个测试一个断言。
遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。
公共函数应跟在变量列表之后。我们喜欢把由某个公共函数调用的私有工具函数紧随在该公共函数后面。这符合了自顶向下原则，让程序读起来就像一篇报纸文章。
关于类的第一条规则是类应该短小。第二条规则是还要更短小。
单一职责原则（SRP）：类或模块应有且只有一条加以修改的理由。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
系统也应该是整洁的。侵害性架构会湮灭领域逻辑，冲击敏捷能力。当领域逻辑受到困扰，质量也就堪忧，因为缺陷更易隐藏，用户故事更难实现。当敏捷能力受到损害时，生产力也会降低。
在所有的抽象层级上，意图都应该清晰可辨。只有在编写POJO并使用类方面的机制来无损地组合其他关注面时，这种事情才会发生。
无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。
鲍勃大叔认为：没什么能比糟糕的代码给开发项目带来更深远和长期的损害了。进度可以重订，需求可以重新定义，团队动态可以修正。但糟糕的代码只是一直腐败发酵，无情地拖着团队的后腿。我无数次看到开发团队蹒跚前行，只因为他们匆匆搞出一片代码沼泽，从此之后命运再也不受自己控制。
注：但是，国内的开发状况却是不管代码质量，只追求快速上线，只追求短期利益，而不做有长期价值的事情。
所以，解决之道就是保持代码持续整洁和简单。永不让腐坏有机会开始。
最后，我认为第17章《味道与启发》可以作为案例来自查和学习，对提高代码质量很有帮助。
欢迎各位在评论区或者私信我一起交流讨论，或者加我主页weixin，备注技术渠道（如博客园），进入技术交流群，我们一起讨论和交流，共同进步！
也欢迎大家关注我的掘金、公众号（码上暴富），点赞、留言、转发。你的支持，是我更文的最大动力！
优雅的注释是一种平衡艺术，它要求我们在不牺牲代码清晰度的前提下，避免过度注释。通过遵循上述原则和技巧，我们可以写出既有助于自己，也有助于他人的注释，从而提升代码的整体质量和可维护性。