代码整洁之道CheckList

总结看完《代码整洁之道》这本书之后得到的CheckList，可以用来指导之后的代码review和重构。

命名

1. 名副其实，替换更好的名字
2. 使用有意义的变量名
3. 用可搜索的名字
4. 类名使用名词，方法名使用动词，方法名+参数使用动词短语
5. 一个概念一个词
6. 良好的描述技巧，共同的文化背景。

函数

1. 函数要短小。一个函数只含有一个if-else
2. 只做一件事
3. 一个函数一个抽象层级。
4. 描述性的名称。
5. 参数越少越好。
6. 使用异常代替错误码。
7. 消除重复，提取出公共方法。
8. 持续打磨，精益求精。

注释

1. 注释是代码表达的失败
2. 一般注释都不会得到维护。

格式

1. 单个文件(class)的最大限制是500行，多数应该小于200行。
2. 像报纸一样，先给出大纲，再逐个给出细节实现。
3. 不同概念的代码块用空格区分开。
4. 减少不必要的空行或注释分散注意力。
5. 团队内使用统一的IDEA格式器，避免代码风格不一致。

对象和数据结构

1. 对象暴露行为，隐藏数据(Service类)。数据结构暴露数据，没有明显的行为(DTO类).

2. 遵守德墨忒尔律，模块不应该了解它所操作对象的内部情形。
   比如这样的代码:

final String  outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath()

可以修改为：

Options opts = ctxt.getOptions();
File scratchFile = opts.getScratchDir();
final String outputDir = scratchFile.getAbsolutePath();

这样的代码依然不好，只是要获取outputDir而已，为什么这个函数要关心Options和File对象？
所以更好的实现方式是，把获取outputDir的实现交给ctxt封装起来。

String outputDir =  ctxt.getOutputDir();

错误处理

1. 使用异常而不是返回码，可以避免很多冗余的检查。

2. 避免使用可控异常，这违反了开闭原则，当底层实现新增一种异常的时候，上层代码也要跟着一起修改。

publc String getSomething throws NullPointException(){};

3. 给出异常的上下文环境，否则抛出的异常没有任何意义。

4. 依照需要定义异常代理类。通过代理类来处理各种异常情况。

5. 定义常规流程，使用策略模式来处理异常情况。

6. 别返回null值，使用空的对象或容器来代替，避免if判断和空指针异常。

边界

1. 封装对于第三方接口和类的调用，这样就把可能的改动限制在封装对象内部，避免第三方接口的修改对自身系统带来的过分影响。

2. 或者可以使用Adapter模式，将我们的接口转换为第三方提供的接口，这样也实现了对第三方接口的包装。

类

1. 类应该短小，体现出来就是一个类应该只有一个权责，当你发现无法准确定义一个类的name时，就该拆分这个类了。

2. 单一权责原则认为，一个类有且只有一条修改的理由。

3. 什么是高内聚？一个类内部应该只有少数变量，这些变量在所有函数中都被使用到。保持高内聚就会得到很多短小的类。

4. 面向修改编程，将系统的修改设计为新增扩展类(开闭原则)。