腐朽、丑陋的代码会随着时间散发出一定的味道，我们需要从这味道中，寻找启发，寻找解决之道。

注释

C1：不恰当的信息

让注释传达一些本来应该在其他地方更好的保存的信息是错误的，比如修改历史记录：作者、最后修改时间、SPR数等元数据不应该在注释中出现。注释只应该描述相关代码和设计的技术性信息。

C2：废弃的注释

过时、无关或不正确的注释就是废弃的注释。

C3：冗余的注释

如果注释描述的是某种充分自我描述的东西，那么注释就是多余的。

注释应该谈及代码自身没有提及的东西。

C4：糟糕的代码

值得编写的注释，就值得好好写。使用正确的语法和拼写，保持整洁。

C5：注释掉的代码

注释掉的代码纯属厌物。看到注释掉的代码，就删除它。别担心，源代码控制系统还会记得它，如果需要，可以重新签出之前的代码。

环境

E1：需要多少步才能实现的构建

构建代码应该是单步的小操作。

不应该从源代码控制系统中一小点一小点签出代码。

不应该需要一系列神秘的指令或环境依赖脚本来构建单个元素。

你应当能够用单个命令签出系统，并用单个指令构建它。

E2：需要多少步才能做到的测试

你应当能够发出单个指令就可以运行全部单元测试。能够运行全部测试是如此基础和重要，应该快速、轻易和直截了当地做到。

函数

F1：过多的函数

函数的参数量应该少。没参数最好。

F2：输出参数

输出参数违反直觉。读者期望参数用于输入而非输出。如果函数非要修改什么东西的状态不可，就修改它所在的对象的状态即可。

F3 标识参数

布尔值参数大声宣告函数做了不止一件事情。他们令人迷惑，应该消灭掉。

F4：死函数

永不被调用的方法应该丢弃。保留死代码纯属浪费。别害怕删除函数。记住源代码控制系统还会记得它。

一般性问题

G1：一个源文件存在多种语言

理想的源文件包括且只包括一种语言。现实上，我们可能会不得不使用多于一种语言，但应该尽力减少源文件中额外语言的数量和范围。

G2：明显的行为未被实现

遵循最小惊异原则，函数或类应该实现其他程序员有理由期待的行为。

G3：不正确的边界行为

没有什么可以替代谨小慎微。别依赖直觉。追索每种边界条件，并编写测试。

G4：忽略安全

忽略安全相当危险，手动控制安全非常有必要。

G5：重复

不要重复自己，一次都不要，尽可能找出重复并消除重复。

G6：在错误的抽象层级上的代码

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

G7：基类依赖于派生类

将概念分解到基类和派生类的最普遍原因是较高层级基类概念可以不依赖于较低层级派生类概念。

G8：信息过多

设计良好的模块有着非常小的接口，可以让你事倍功半。

良好的整洁的代码 不会散发腐朽的味道，如有过，就要警惕