代码整洁之道笔记

第二章  有意义的命名

1 避免误导，根据对象的特点使用正确的单词，例如accountList用来指一组账号，但如果底层的实现是vector而不是list就会给调用者误解，所以应当使用accountGroup,甚至 accounts都比accountList好

2 尽量避免不恰当的缩写，使用可搜索的名称，如果缩写不得当可能导致搜索不出来。

3 尽量将原生的变量封装/重命名为有意义的名称,例如将double封装成Time，更能告诉阅读者这是个什么变量，另一方面可以抑制潜在的类型转换

第三章 函数

1   函数应当短小，尽量将一些单独的功能封装成函数由主函数调用，建议的函数长度为20行。

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

    无副作用：函数在做一件事的时候不应该做另一件事，如果必须要做，需要在命名中体现，例如如果要在做某件事的时候初始化一个东西，初始化要在函数名中体现。

     自顶向下的读代码：向下规则

3   函数参数越少越好

     将布尔型变量传入函数是一个绝对的错误，应该将其分成两个无参数的子函数。

     对于二元函数尽量使用一些机制使其转换成一元函数。

     如果有三个以上的参数，就可以考虑把其中的一部分封装成类了。

4    ！！！尽量避免 输出参数

5   可以使用trycatch来代替返回错误码

6  别重复自己，当需要改动时会导致漏改。

第四章  注释

好注释

     1  阐释参数或返回值的意义，或者警示函数的使用场景等，例如警示该函数是线程不安全的

     2  解释某些看似不合理但是却极为重要的东西

坏注释：

     1  对于一些显而易见的或者易读的程序不要使用多余的注释，能够利用变量/函数命名表示的东西不要使用注释

     2  不要使用误导性质的注释，这比没有注释还糟糕

     3  不要使用日志型的注释，这会使代码凌乱不堪

     4  不要简单的注释掉源代码，因为阅读者不知道这段代码有什么用，什么情况下会启用，或者改不改删除，这种情况应该添加一定的说明或者if控制

     5 注释本身要解释清楚代码（如果需要的话），而不是只讲意图，例如一些复杂的关于长度的计算过程等

第五章：格式

    1   垂直格式： 在封包声明，导入声明和每个函数之间都有空白行隔开，方便阅读。

    2   垂直距离： 相互依赖/调用的函数不应该相隔太远，调用者尽量放在被调用者的上面。

第六章 对象与数据结构

得墨忒耳定律－－对象 O 的 M 方法，可以访问/调用如下的：

1. 对象 O 本身
2. M 方法的传入参数
3. M 方法中创建或实例化的任意对象
4. 对象 O 直接的组件对象
5. 在M范围内，可被O访问的全局变量

   应尽量避免链式调用，可以将链式调用封装起来，以免暴露内部结构。

   对象隐藏数据，暴露操作数据的函数       数据结构暴露其数据，没有提供有意义的函数

第七章  错误处理

1  使用异常而不是返回错误码，并且需要给出发生异常的环境说明

2  非受检异常允许你在适当的地方处理异常，而适当的地方就是异常影响代码执行逻辑的地方，不管做哪种类型的应用，都应该尽可能向用户隐藏异常的发生，除非发生了不可挽救的状况，这才是符合最小惊讶原则的设计；

3 如果一个方法在出状况的时候返回null，那么调用者都要通过频繁的检查返回值来判定是否出错，一旦忘了这件事情就有可能出错，既然null是一种异常状况，那么用抛出异常的方式来代替返回null明显是更好的做法。

第八章 边界

第九章 单元测试