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

Part1 让代码比你来时更干净

• 编写代码的难度，取决于周边代码的阅读难度。想要快速实现需求，想要快速完成任务，想要轻松的写代码，请先让你书写的代码整洁易读。

• 保持整洁的习惯，发现脏代码就要及时纠正。花时间保持代码代码整洁，这不但有关效率，还有关项目的生存。

• 程序员遵从不了解混乱风险的产品经理(策划)的意愿，都是不专业的做法。

• 让代码比你来时更干净：如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

• 赶上期限的唯一方法，做得更快的唯一方法，就是在始终尽可能保持代码的整洁。

Part2 整洁代码的命名法则

• 要点一：要名副其实。一个好的变量、函数或类的名称应该已经答复了所有的大问题。一个好名称可以大概告诉你这个名称所代表的内容，为什么会存在，做了什么事情，应该如何用等。

• 要点二：要避免误导。我们应该避免留下隐藏代码本意的错误线索，也应该避免使用与本意相悖的词。

• 要点三：尽量做有意义的区分。尽量避免使用数字系列命名（a1、a2…….aN）和没有意义的区分。

• 要点四：尽量使用读得出来的名称。如名称读不出来，讨论的时候会不方便且很尴尬。

• 要点五：尽量使用可搜索的名称。名称长短应与其作用域大小相对应，若变量或常量可能在代码中多处使用，应赋予其以便于搜索的名称。

• 要点六：取名不要绕弯子。取名要直白，要直截了当，明确就是王道。

• 要点七：类名尽量用名词。类名尽量用名词或名词短语，最好不要是动词。

• 要点八：方法名尽量用动词。方法名尽量用动词或动词短语。

• 要点九：每个概念对应一词，并一以贯之。对于那些会用到你代码的程序员，一以贯之的命名法简直就是天降福音。

• 要点十：通俗易懂。应尽力写出易于理解的变量名，要把代码写得让别人能一目了然，而不必让人去非常费力地去揣摩其含义。

• 要点十一：尽情使用解决方案领域专业术语。尽管去用那些计算机科学领域的专业术语、算法名、模式名、数学术语。

• 要点十二：要添加有意义的语境。需要用有良好命名的类，函数或名称空间来放置名称，给读者提供语境。若没能提供放置的地方，还可以给名称添加前缀。

Part3 整洁代码的函数书写准则

• 第一原则：短小。若没有特殊情况，最好将单个函数控制在十行以内。

• 第二原则：单一职责。函数应该只做一件事情。只做一件事，做好这件事。

• 第三原则：命名合适且具描述性。长而具有描述性的名称，比短而令人费解的名称好。当然，如果短的名称已经足够说明问题，还是越短越好。

• 第四原则：参数尽可能少。最理想的函数参数形态是零参数，其次是单参数，再次是双参数，应尽量避免三参数及以上参数的函数，有足够的理由才能用三个以上参数。

• 第五原则：尽力避免重复。重复的代码会导致模块的臃肿，整个模块的可读性可能会应该重复的消除而得到提升。

Part4 整洁代码的格式准则

整洁代码的书写格式，可以遵从如下几个原则：

• 第一原则：像报纸一样一目了然。优秀的源文件也要像报纸文章一样，名称应当简单并且一目了然，名称本身应该足够告诉我们是否在正确的模块中。源文件最顶部应该给出高层次概念和算法。细节应该往下渐次展开，直至找到源文件中最底层的函数和细节。

• 第二原则：恰如其分的注释。带有少量注释的整洁而有力的代码，比带有大量注释的零碎而复杂的代码更加优秀。

• 第三原则：合适的单文件行数。尽可能用几百行以内的单文件来构造出出色的系统，因为短文件通常比长文件更易于理解。

• 第四原则：合理地利用空白行。在每个命名空间、类、函数之间，都需用空白行隔开。

• 第五原则：让紧密相关的代码相互靠近。靠近的代码行暗示着他们之间的紧密联系。所以，紧密相关的代码应该相互靠近。

• 第六原则：基于关联的代码分布。

  • 变量的声明应尽可能靠近其使用位置。

  • 循环中的控制变量应该在循环语句中声明。

  • 短函数中的本地变量应当在函数的顶部声明。

  • 对于某些长函数，变量也可以在某代码块的顶部，或在循环之前声明。

  • 实体变量应当在类的顶部声明。

  • 若某个函数调用了另一个，就应该把它们放到一起，而且调用者应该尽量放到被调用者上面。

  • 概念相关的代码应该放到一起。相关性越强，则彼此之间的距离就该越短。

• 第七原则：团队遵从同一套代码规范。一个好的团队应当约定与遵从一套代码规范，并且每个成员都应当采用此风格。

Part5 整洁类的书写准则

• 原则一：合理地分布类中的代码。 类中代码的分布顺序大致是：

  1. 公有静态常量

  2. 私有静态变量

  3. 公有普通变量

  4. 私有普通变量

  5. 公共函数

  6. 私有函数

• 原则二：尽可能地保持类的封装。尽可能使函数或变量保持私有，不对外暴露太多细节。

• 原则三：类应该短小，尽量保持单一权责原则。类或模块应有且只有一条加以修改的理由。

• 原则四：合理提高类的内聚性。我们希望类的内聚性保持在较高的水平。内聚性高，表示类中方法和变量相互依赖，相互结合成一个逻辑整体。

• 原则五：有效地隔离修改。类应该依赖于抽象，而不是依赖于具体细节。尽量对设计解耦，做好系统中的元素的相互隔离，做到更加灵活与可复用。