代码整洁之道

一、注释
1、不恰当的信息
让注释传达本该更好地在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息，是不恰当的。例如，修改历史记录只会用大量过时而无趣的文本搞乱源代码文件。通常，作者、最后修改时间、SPR数等元数据不该在注释中出现。注释只应该描述有关代码和设计的技术性信息。
2、废弃的注释
过时、无关或不正确的注释就是废弃的注释。注释会很快过时。最好别编写将被废弃的注释。如果发现废弃的注释，最好尽快更新或删除掉。废弃的注释会远离它们曾经描述的代码，变成代码中无关和误导的浮岛。
3、冗余注释
如果注释描述的是某种充分自我描述了的东西，那么注释就是多余的，例如：
i++； // increment i
另一个例子是除函数签名之外什么也没多说（或少说）的Javadoc：

注释应该谈及代码自身没提到的东西。
4、糟糕的注释
值的编写的注释，也值得好好写。如果要编写一套注释，就花时间保证写出最好的注释。字斟句酌。使用正确的语法和拼音。别闲扯，别画蛇添足，保持简洁。
5、注释掉的代码
看到被注释掉的代码会令我抓狂。谁知道它有多旧？谁知道它有没有意义？没人会删除它，因为大家都假设别人需要它或是有进一步计划。

二、环境
1、需要多步才能实现的构建
构建系统应该是单步的小操作。不应该从源代码控制系统中一小点一小点签出代码。不应该需要一系列神秘指令或环境依赖脚本来构建单个元素。不应该四处寻找额外的小JAR、XML文件和其他系统所需的杂物。你应当能够用单个命令签出系统，并用单个指令构建它。
2、需要多步才能够做到的测试
你应当能够发出单个指令就可以运行全部单元测试。能够运行全部测试是如此基础和重要，应该快速、轻易和直截了当地做到。
三、函数
1、过多的参数
函数的参数量应该少。没参数最好，一个次之、两个、三个再次之。三个以上的参数非常值得质疑，应该坚决避免。
2、输出参数
输出参数违反直觉。读者期望参数用于输入而非输出。如果函数非要修改审核东西的状态不可，就修改它所在对象的状态好了。
3、标识参数
布尔值参数大声宣告函数做了不止一件事。他们令人迷惑，应该消灭掉。
4、死函数
永不被调用的方法应该丢弃。保留死代码纯属浪费。别害怕删除函数。记住，源代码控制系统还会记得它。
四、一般性问题
1、一个源文件中存在多种语言

2、明显的行为未被实现

3、不正确的边界行为

没什么可以替代谨小慎微。每种边界条件、每种极端情形、每个异常都代表了某种可能搞乱优雅而直白的算法的东西。别依赖直觉。追索每种边界条件，并编写测试。
4、忽视安全

5、重复

6、在错误的抽象层级上的代码
创建分离较高层级一般性概念与较低层级细节概念的抽象模型，这很重要。有时，我们创建抽象类来容纳较高层级的概念，创建派生类类容纳较低层次概念。这样做的时候，需要确保分离完整。所有较低层级概念放在派生类中，所有较高层级概念放在基类中。
7、基类依赖于派生类

8、信息过多
设计良好的模块有着非常小的接口，让你能事半功倍。设计低劣的模块有着广阔、深入的接口，你不得不事倍功半。设计良好的接口并提供许多需要依靠的函数，所以耦合度也较低。设计低劣的接口提供大量你必须调用的函数，耦合度较高。

9、死代码

10、垂直分割

11、前后不一致

12、混淆视听

13、人为耦合

14、特性依恋
类的方法只应对其所属类中的变量和函数感兴趣，不该垂青其他类中的变量和函数。当方法通过某个其他对象的访问器和修改器来操作该对象的内部数据，则它就依恋于该对象所属类的范围。它期望自己在那个类里面，这样就能直接访问它操作的变量。

15、选择算子参数
没有什么比在函数调用末尾遇到一个false参数更为可憎的事情了。那个false是什么意思？如果它是true，会有什么变化吗？不仅是一个选择算子参数的目的难以记住，每个选择算子参数将多个函数帮到了一起。选择算子参数只是一种避免把大函数切分为多个小函数的偷懒做法。

选择算子不一定是boolean类型，可能是枚举元素、整数或任何一种用于选择函数行为的参数。使用多个函数，通常优于单个函数传递某些代码来选择函数行为。
16、晦涩的意图

17、位置错误的权责

18、不恰当的静态方法

19、使用解释性变量
让程序可读的最有力方法之一就是将计算过程打散成在用有意义的单词命名的变量中放置的中间值。

20、函数名应该表达其行为

21、理解算法
好多可笑代码的出现，是因为人们没花时间去理解算法。他们硬塞进足够多的if语句和标识，从不真正停下来考虑发生了什么，勉强让系统能工作。

22、把逻辑依赖改为物理依赖
如果某个模块依赖于另一个模块，依赖就该是物理上的而不是逻辑上的。依赖折模块不应对被依赖者模块有假定。它应当明确地询问后者全部信息。
23、用多态替代if/else或switch/cache

24、遵循标准约定

25、用命名常量代替魔术数
在代码中出现原始形态数字通常来说是坏现象。应该用良好命名的常量来隐藏它。
26、准确

27、结构基于约定

18、封装条件

29、避免否定性条件

30、函数只该做一件事

31、掩饰时序耦合

32、别随意
构建代码需要理由，而且理由应与代码结构相契合。如果结构显得太随意，其他人就会想修改它。如果结构自始至终保持一致，其他人就会使用它，并且遵循其约定。
33、封装边界条件
边界条件难以追踪，把处理边界条件的代码集中到一处，不要散落于代码中。
34、函数应该只在一个抽象层级上
函数中的语句应该在用以抽象层级上，该层级应该是函数名所示操作的下一层。

35、在较高层级放置可配置数据
如果你有个已知并在较高抽象层级的默认常量或配置值，不要将它埋藏到较低层级的函数中。把它作为较高层级函数调用较低层级函数时的一个参数。
位于较高层级的配置性常量易于修改。它们向下贯穿应用程序。应用程序的较低层级并不有用这些常量的值。
36、避免传递浏览

五、Java
1、通过使用通配符避免过长的导入清单

2、不要继承常量
六、名称
1、采用描述性名称

2、名称应与抽象层级相符

3、尽可能使用标准命名法

4、无歧义的名称
5、为较大作用范围选用较长名称
6、避免编码

7、名称应该说明副作用

七、测试
1、测试不足

2、使用覆盖率工具

3、别略过小测试

4、被忽略的测试就是对不确定事物的疑问

5、测试边界条件

6、全面测试相近的缺陷

7、测试失败的模式有启发性

8、测试覆盖率的模式有启发性

9、测试应该快速