1. 应用程序级别代码坏味道
1.1. 布尔盲点
-
1.1.1. 由于函数使用布尔值而导致的信息缺失
-
1.1.2. 解决方案是将布尔替换为枚举类型
1.2. 组合爆炸
-
1.2.1. 不同的代码使用不同的参数组合来执行同一件事情的产物
-
1.2.2. 解决方案使用泛型
1.3. 人为复杂性
-
1.3.1. 简单的架构复杂化
-
1.3.2. 解决方案务必保持软件的简单易懂（Keep It Simple，Stupid，KISS）
1.4. 数据泥团
-
1.4.1. 相同的字段同时出现在不同的类和参数列表中时
-
1.4.1.1. 说明系统中缺少类定义
-
1.4.2. 识别并泛化缺失的类可以降低系统的复杂度
1.5. 粉饰注释
- 1.5.1. 注释中用优美的词句掩盖代码的缺点
1.6. 重复代码
-
1.6.1. 多次出现的代码
-
1.6.1.1. bug=技术债务=程序员支出
-
1.6.2. 解决方案将这些代码添加到当前项目的可重用类并放置在类库中
-
1.6.3. 解决方案2：面向方面编程（AOP）是另一种删除样板代码的方法
1.7. 意图不明
- 1.7.1. 他人无法轻易理解代码的意图
1.8. 可变的变量
-
1.8.1. 不同操作之间多次更改的变量
-
1.8.2. 消除变量的可变性，使其值更易于预测
-
1.8.3. 函数编程
-
1.8.3.1. LINQ
1.9. 怪异的解决方案
-
1.9.1. 源代码中解决同样问题的方案多种多样
-
1.9.1.1. 源代码中解决同样问题的方案多种多样
-
1.9.1.2. 没有制定统一标准而造成
-
1.9.1.3. 程序员并没有意识到系统中已经存在解决方案
-
1.9.2. 解决方案：不同的重复的解决方案编写新类，并将最整洁最高效的方式添加到类中
-
1.9.3. 解决方案2：适配器模式来统一不同的系统接口
1.10. 霰弹式修改
-
1.10.1. 一种改动需要在多个类中进行修改
-
1.10.1.1. 复杂的代码还会导致程序员认知负担过重
-
1.10.2. 减少耦合可以使类更易于测试
-
1.10.3. 将不属于类的代码移出到恰当的位置可以提高应用程序的可读性、可维护性与可扩展性
1.11. 解决方案蔓延
-
1.11.1. 一种职责在不同的方法、类甚至库中均被实现
-
1.11.2. 单一职责转移到同一个类中
1.12. 不可控的副作用
-
1.12.1. 在产品中由于无法被质量保证过程发现而引起的问题
-
1.12.2. 唯一的办法就是重构代码使其完全可测，并可以在调试期间查看变量的状态以确保程序的正确性。
2. 类级别代码坏味道
2.1. 过高的圈复杂度
-
2.1.1. 大量的分支和循环
-
2.1.2. 1～10
-
2.1.2.1. 代码简单没有风险
-
2.1.3. 11～20
-
2.1.3.1. 较复杂，风险相对较低
-
2.1.4. 21～50
-
2.1.4.1. 引起注意，中等风险
-
2.1.5. 超过50
-
2.1.5.1. 风险高，必须重构
-
2.1.6. 解决方案
-
2.1.6.1. 使用工厂模式替换switch语句
-
2.1.6.2. 改善if语句条件检测的可读性
-
2.1.6.3. LINQ语句替换循环
2.2. 发散式变化
-
2.2.1. 对代码进行一处更改，但是发现自己必须更改许多不相关的方法
-
2.2.2. 原因
-
2.2.2.1. 类结构不良造成
-
2.2.2.2. 复制粘贴代码
-
2.2.2.3. 利用基类和子类的关系实现继承
2.3. 向下类型转换
- 2.3.1. 将基类转换为它的一个子类
2.4. 过度的字面量使用
-
2.4.1. 将字面量保存在常量中
-
2.4.2. 将字符串字面量放置在本地化资源文件中
2.5. 依恋情结
- 2.5.1. 当一个方法花费大量的时间处理类中的代码而非自身的代码
2.6. 狎昵（xiá nì）关系
-
2.6.1. 一个类若依赖另一个类的实现细节
-
2.6.2. 类之间不应当相互依赖
-
2.6.3. 类应当是自包含的
-
2.6.4. 类之间应该尽可能少地互相了解彼此的底细
2.7. 不恰当的暴露
-
2.7.1. 类暴露了其内部细节
-
2.7.2. 打破了面向对象编程的封装原则
2.8. 巨大的类
- 2.8.1. 务必令其尽可能小巧、整洁、易于阅读
2.9. 冗赘类
-
2.9.1. 一种并不包含什么有效操作的类
-
2.9.2. 和其他包含相似意图的类合并
-
2.9.3. 削减继承层次结构
-
2.9.3.1. 理想的继承层次是1
-
2.9.4. 非常小的类还可以考虑采用内联的处理方法
2.10. 中间人类
-
2.10.1. 仅将功能委托给其他对象
-
2.10.2. 舍弃中间人直接和处理相应职责的类进行交互
-
2.10.3. 将其与现有类合并
2.11. 孤立的变量和常量类
-
2.11.1. 使用一个独立的类来定义系统不同部分使用的变量和常量
-
2.11.2. 丢失其上下文而无法表达任何实际含义
-
2.11.3. 移动到使用它们的位置
2.12. 基本类型偏执
-
2.12.1. 使用常量作为字段名称
-
2.12.2. 不恰当地使用常量保存信息
-
2.12.3. 使用基本类型值而非使用对象
2.13. 被拒绝的遗赠
-
2.13.1. 一个类继承自另一个类，却没有使用其所有方法
-
2.13.2. 考虑是否真的需要基类
2.14. 夸夸其谈未来性
-
2.14.1. 一个类的功能现在不需要，但是将来可能用到
-
2.14.2. 死代码，应当将其删除
2.15. 命令，而非询问
-
2.15.1. 将数据和操作数据的方法绑定在一起
-
2.15.2. 一个对象包含逻辑，并要求其他包含数据的对象提供数据以供其执行操作，则应当将逻辑与数据合并到一个类中
2.16. 临时字段
-
2.16.1. 不需要在对象的整个生命周期内存在的成员变量
-
2.16.2. 将临时字段及操作这些字段的方法移动到它们自己的类中
3. 方法级别的代码坏味道
3.1. 不合群的方法
-
3.1.1. 一个类中和其他方法截然不同的方法
-
3.1.2. 考虑该方法的目的
-
3.1.2.1. 确定哪里才是该方法最合适的落脚点了
3.2. 无用的代码
-
3.2.1. 现存的方法无人使用
-
3.2.2. 要识别无用的代码并将其删除
-
3.2.3. 构造器、属性和变量也应遵循相同的原则
3.3. 过多的返回数据
- 3.3.1. 远超客户端的调用
3.4. 过长或过短的标识符
- 3.4.1. 标识符应当既能描述对象又简明扼要
3.5. 过长的代码行
- 3.5.1. 应尽量将其格式化，在点号和逗号处换行
3.6. 过长的方法
- 3.6.1. 方法应当只负责执行单一任务
3.7. 参数过多
- 3.7.1. 方法参数数目超过3个
3.8. 过度耦合的消息链
-
3.8.1. 当一个方法调用一个对象，继而调用另一个对象
-
3.8.2. 消息链违反了迪米特法则
-
3.8.2.1. 类只应当和离其最近的邻居通信
-
3.8.2.2. 重构类，将所需的状态和行为放在距离其更近的位置
京ICP备14020293号-4