神秘的命名（Mysterious Name）
阅读代码时，难以理解的命名，将体验很差。整洁代码的重要一环就是好的名字
重复的代码（Duplicated Code）
如果在一个以上的地方看到重复的代码结构，那么可以肯定，将其合而为一，程序将变得更好。因为，一旦有重复代码存在，阅读这些代码时必须加倍仔细，留意其中的差异。如果有要修改的重复代码，你必须找出所有的副本来修改。
过长的函数（Long Function）
根据经验、活得最长、最好的程序，其中的函数都比较短。小函数易于理解的关键还是良好的命名。
总之应该积极的分解函数。我们遵循这样一条原则：每当需要以注释来说明点什么东西的时候，我们就需要把说明的东西写进一个独立的函数中，并以其用途命名。
过长的参数列表（Long Parameter List）
全局变量不太好，但过长的参数列表也常常令人困惑
全局数据（Global Data）
全局变量越多，处理的难度越大
可变数据（Mutable Data）
对数据的修改经常导致出乎意料的结果和难以发现的bug
发散式变化（Divergent Change）
我们希望程序更容易修改——一旦需要修改，我们希望能够跳到系统的某一点修改，只在该处修改。
散弹式修改（Shotgun Surgery）
如果遇到莫种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。如果需要修改的代码分散在四处，你不但很难找到他们，也很容易错过某个重要的修改。
依恋情节（Feature Envy）
最大化区域内部的交互、最小化跨区域交互。
数据泥团（Data Clumps）
你常常可以在很多地方看到相同的三两项数据：两个类中相同的字段、许多函数签名中相同的参数。
基本类型偏执（primitive Obsession）
很多程序员不愿意创建对自己的问题域有用的基本类型，如钱、坐标、范围。
字符串就是这种坏味道的培养皿。
重复的switch（repeated Switches）
任何的switch语句都应该用多态取代条件表达式
循环语句（loops）
使用管道操作代替
冗赘的元素（Lazy Element）
没有必要
夸夸其谈通用性（Speculative Generality）
没太大作用
临时字段（Temporary Field）
未被使用
过长的消息链（Message Chains）
一个对象请求另一个对象，然后再向后者请求另一个对象，然后在请求另一个对象…,这就是消息链
中间人（Middle Man）
人们可能过度运用委托。你也许会看到某个类的接口有一半的函数都委托给其他类，这样就是过度运用
内幕交易（Insider Trading）
如果两个模块总是在咖啡机旁边窃窃私语，就应该用搬移函数和搬移字段减少他们私下交流
过大的类（large class）
你可以运用提炼函数将几个变量一起提炼到新类
异曲同工的类（alternative class with different interfaces）
今天使用这个类明天可以替换成另一个类
纯数据的类（data class）
运用封装记录把它们封装起来
被拒绝的遗赠（refused bequest）
子类应该继承超类的函数和数据
注释（comments）
当你感觉需要写注释时。请先尝试重构，试着让所有的注释变得多余
扫一扫
2947
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
