《代码整洁之道》阅读小记

• 让变量的命名名副其实，如果变量名称需要注释来补充，那就不算是名副其实。

• 废话就是冗余，Variable一词永远不应该出现在变量名中。

• 类名和对象名应该是名词或名词短语。

• 方法名应该是动词或动词短语。

• 可以考虑将相应的构造器设置为private，强制使用参数的静态工厂方法名。

• 函数的第一规则是要短小，第二条规则是要更短小。

• 每个函数都只说一件事，而且，每个函数都依序把你带到下一个函数，这就是函数应该达到的短小程度。

• 函数应该做一件事。做好这件事。只做这一件事。

• 最理想的参数数量是零（零参数函数），其次是一（单参数函数），再次是二（双参数函数），应尽量避免三（三参数函数）。

• 如果函数看来需要两个，三个或者三个以上参数，就说明其中一些参数应该封装为类了。

• 用代码本身来表达意图，而不是通过注释。好的代码不需要注释。

• 随着时间的流逝，注释会越来越背离代码。因为程序员一般不维护注释。

• 不要注释代码：让别人觉得想删又怕以后有用。

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

• 一般而言，自上向下展示函数调用依赖顺序。也就是说，被调用的函数应该放在执行调用的函数下面。

• 一个开发小组应该使用一样的代码风格来编写代码。
  

• 对象暴露行为，隐藏数据；数据结构暴露数据，没有明显的行为。

• 错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法。

• 测试代码和生产代码一样重要。它需要被思考，被设计和被照料。它该像生产代码一样保持整洁。

• 把单元测试清晰地拆分为三个环节：1.构造测试数据；2.操作测试数据；3.检验操作是否得到期望的结果。

• Given-when-then约定：given一个上下文，指定测试预设；when进行一系列操作，即所要执行的操作；Then得到一系列可观察的后果，即需要检测的断言。

• 系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。

• 在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。

• 软件系统应该将启始过程和运行过程逻辑分离开。对象的初始化和运行逻辑分离，spring的IOC就遵循这一法则。

• 单一权责原则（SRP）认为方法/类/组件应当只有一个修改的理由。并发设计自身足够复杂到成为修改的理由，所以也该从其他代码中分离出来。

• 不要将系统错误归咎于偶发事件。

• 注释只应该描述有关代码和设计的技术性信息。

• 注释应该提及代码自身没提到的东西。

• 删除注释掉的代码。

• 基类应该对派生类一无所知。

• 用多态代替If/Else或Switch/Case。

• 魔术数指的是那些不能自描述的数字，如果数字可以自描述，不需要使用变量来定义它。

• 如果要让函数之间有时序耦合，比较好的做法是让上一个函数产生下一个函数所需的结果。

• 名称的作用范围越大，名称就该越长越准确。