代码异味

程序开发领域，代码中的任何可能导致深层次问题的症状都可以叫做代码异味（Code smell）。

通常，在对代码做简短的反馈迭代时，代码异味会暴露出一些深层次的问题，这里的反馈迭代，是指以一种小范围的、可控的方式重构代码。基于这些暴露的问题，人们会进一步的检查设计和代码中是否还存在别的代码异味，然后再做进一步的重构。从负责重构的开发者的角度来看，代码异味可以启发何时重构，如何重构。因此，可以说代码异味推动着重构的进行。

该术语似乎由肯特·贝克于90年代后期，在WardsWiki上首次使用。且自从在Refactoring. Improving the Design of Existing Code.[1]被提到过，使用率就大大的提高。代码异味同时也是敏捷开发者常用的术语。

什么是，或者不是代码异味，是一个主观的判断，通常因语言、开发者、开发方法的不同而不同。对于Java开发语言，有些工具，比如Checkstyle、PMD和 FindBugs可以自动检测一些代码异味。

常见的代码异味

• 代码重复: 相同或者相似的代码存在于一个以上的地方。
• 长方法: 一个非常长的方法、函数或者过程。
• 巨类: 一个非常庞大的类。
• 太多的参数: 函数或者过程的冗长的参数列表使得代码可读性和质量非常差。
• 特性依恋: 一个类过度的使用另一个类的方法。
• 亲密关系: 一个类依赖另一个类的实现细节。
• 拒绝继承: 子类以一种‘拒绝’的态度，覆盖基类中的方法，换句话说，子类不想继承父类中的方法，参考里氏替换原则。
• 冗余类 / 寄生虫: 一个功能太少的类。
• 人为的复杂: 在简单设计已经满足需求的时候，强迫使用极度复杂的设计模式。
• 超长标识符: 尤其，在软件工程中，应该毫无保留的使用命名规则来消除歧义。
• 超短标识符: 除非很明显，一个变量名应该反映它的功用。
• 过度使用字面值: 为提高可读性和避免编码错误，应该使用命名常量。此外，字面值可以且应该在可能的情况下，独立存放于资源文件或者脚本中，在软件部署到不同区域时，可以很方便地本地化。

参见

• 反模式
• 编程原则
• 靜態程序分析工具列表（英语：List of tools for static code analysis）
• 软件腐败
• 设计异味
• 軟體缺陷指標

引用

1. Fowler, Martin. Refactoring. Improving the Design of Existing Code. Addison-Wesley. 1999. ISBN 0-201-48567-2. 

外部链接

• CodeSmell at c2.com（页面存档备份，存于互联网档案馆）
• Taxonomy of code smells