《代码整洁之道》读书笔记

内容会持续更新，有错误的地方欢迎指正，谢谢！

前言

这本书为什么值得读？
写了一堆可执行没Bug的代码的确是OK的，但是不优雅、不可读呀，为了追求优雅性、可读性，还是建议读读这本书。本书提出了一个观点：代码质量与其整洁度成正比，干净的代码，既在质量上可靠，也为后期维护、升级奠定了良好基础。

为什么会产生不好的代码？
抛去个人能力不谈，需求变化违背了初期设计、需求一直在变更、进度太紧都是导致好代码变质的诱因。
我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新的一天，等有朝一日再来清理，然而中国古训有云，“明日复明日，明日何其多”。保持整洁的习惯，发现脏代码就要及时纠正，不但有关效率，还有关项目的生存。

代码整洁的好处有啥？
制造混乱只会立刻拖慢你，让你错过期限，赶上期限的唯一方法、也是做得更快的唯一方法：就是始终尽可能保持代码的整洁。整洁的代码从不隐藏设计者的意图。

代码整洁之道的核心是啥？
让代码比你来时更干净。

命名规则

多花时间去选个好名字，是很值得的。

要点一：名副其实。这个名称所代表的内容，为什么会存在，做了什么事情，应该如何用等。
要点二：避免误导。避免留下隐藏代码本意的错误线索，比如：用accountList的前提是，它真的是List类型。
要点三：要有意义。避免使用数字命名（a1、a2…….aN），避免没有意义的区分（ProductInfo和ProductData）。
要点四：读得出来。如名称读不出来，讨论时会很尴尬。
要点五：便于搜索。若变量或常量可能在代码中多处使用，应赋予其以便于搜索的名称。
要点六：不要绕弯。要直截了当。
要点七：类名尽量用名词或名词短语。比如Customer，WikiPage，AddressParser。
要点八：方法名尽量用动词或动词短语。比如GetName、SetName。
要点九：每个概念对应一词，并一以贯之。比如：别混用controller、manager、driver，要专一。
要点十：通俗易懂。
要点十一：尽情使用计算机科学领域的专业术语，因为只有程序员会看你代码。
要点十二：添加必要的语境。某个类里的变量名就没必要在类里的函数名、变量名提及这个类名了，否则当你搜索的时候，所有相关的东西就都会出来了；若在没有语境的地方取名字，就可以给名称添加前缀。

函数书写原则

第一原则：短小。若没有特殊情况，最好将单个函数控制在十行以内。函数短小这个议题，仁者见仁智者见智，在实际编码过程中任何人都很难做到严格遵守，但是，若想写出整洁的代码，应该去向短小的函数靠拢。
第二原则：单一职责。函数应该只做一件事，做好这件事就好，要判断函数是不是只做了一件事情，还有一个方法，就是看能否再拆出一个函数。
第三原则：命名合适且具描述性。长而具有描述性的名称，比短而令人费解的名称好；当然，如果短的名称已经足够说明问题，那还是越短越好。
第四原则：参数尽可能少。最理想的函数参数形态是零参数，应尽量避免大于等于三个参数的函数。函数参数中出现标识符参数是非常不推崇的做法，有标识符参数的函数，很有可能不止在做一件事，正确的做法：将有标识符参数的函数一分为二，对标识符为true和false分别开一个函数来处理。
第五原则：避免重复，重复可能是软件中一切邪恶的根源。面向对象的继承就是最好的消除重复的方法。

优秀代码的格式原则

第一原则：像报纸一样一目了然。你从上到下阅读报纸时，在顶部，你希望有个抬头，告诉你故事主题；第一段是整个故事的大纲，但隐藏了故事细节；接着读下去，细节逐渐增加。
第二原则：恰如其分的注释。带有少量注释的整洁而有力的代码，比带有大量注释的零碎而复杂的代码更加优秀；另外，大多数程序员们不能坚持（或者因为忘了）去维护注释，就会导致一些注释会造成误解。
第三原则：合适的单文件行数。尽可能用几百行以内的单文件，因为短文件通常比长文件更易于理解。
第四原则：合理利用空白行（留白）。在每个类、函数之间，都需用空白行隔开，这能极大地影响到代码的视觉外观，可读性也会大大提升。
第五原则：让紧密相关的代码相互靠近。
第六原则：基于关联的代码分布。

1. 变量的声明应尽可能靠近其使用位置。
2. 短函数中的局部变量应当在函数的顶部声明。
3. 对于某些长函数，局部变量也可以在某代码块的顶部，或在代码块里的循环之前声明。
4. 类的成员变量应当在类的顶部声明。
5. 若某个函数调用了另一个，就应该把它们放到一起，而且调用者应该尽量放到被调用者上面。A函数调用B函数，B函数调用C函数，那么最好的顺序就是ABC，而且距离最好不要太远，否则当我们看的时候就需要跳来跳去。
6. 概念相关的代码应该放到一起。相关性越强，则彼此之间的距离就该越短。

第七原则：团队遵从同一套代码规范。

整洁类的书写原则

原则一：合理地分布类中的代码。 类中代码的分布顺序大致是：（符合自上而下的原则，让程序读起来更像一篇报纸文章）

1. 公有静态常量
2. 私有静态变量
3. 公有普通变量
4. 私有普通变量
5. 公共函数
6. 私有函数

原则二：尽可能地保持类的封装。尽可能使函数和变量保持私有，不对外暴露太多细节。
原则三：类应该短小。每个类尽量做到单一权责。如果名字不好起或者不能很好地用一句话说明这个类是干什么的，那就说明这个类可能有些大了。比如：一个类既在管理组件，又在管理版本信息，那么这个类就应该拆分为两个类，以做到单一权责。
原则四：合理提高类的内聚性。希望类的内聚性保持在较高的水平，类应该只有少量的成员变量，类中的每个方法都应该操作一个或者多个这种变量。
原则五：有效地隔离细节的修改。类应该依赖于抽象，而不是依赖于具体细节（这句话就是依赖倒置原则）。我们可以借助接口、抽象类来隔离这些细节的改变所带来的影响，也就是尽量对设计解耦，做好系统中的元素的相互隔离，做到更加灵活与可复用。

参考

毛星云的博客 https://blog.csdn.net/poem_qianmo/article/list/2