如果代码可以被团队中的每个人轻松理解，那么它就是整洁的。除了原始作者之外，其它开发人员也可以阅读和改进整洁的代码。可理解性带来了可读性、可修改性、可扩展性和可维护性。
一般规则
- 遵守标准约定。
- 保持简单愚蠢。越简单越好。尽可能减少复杂性。
- 童子军的规则。让营地比你想象的更干净。
- 一定要找到根本原因。总是寻找问题的根本原因。
设计规则
- 保持高水平的数据可配置。
- 与if/else或switch/case相比，有限使用多态。
- 分离多线程代码
- 防止过度配置
- 使用依赖注入。
- 迪米特法则。一个类应该只知道它的直接依赖项。
可理解性的建议
- 一致性。如果你以某种方式做某事，用同样的方式做所有类似的事情。
- 使用解释性变量。
- 封装边界条件。边界条件很难追踪。把它们的处理放在一个地方。
- 与原始类型相比，优先使用专用的值对象。
- 避免逻辑依赖关系。不要让一个方法的正确性取决于同一类中的其他内容。
- 避免反向条件。
命名规则
- 选择描述性和明确的名称。
- 做有意义的区别。
- 使用好叫的名字。
- 使用好搜索的名称。
- 用命名常量替换魔法数字。
- 避免编码(encoding)。不要添加前缀或类型信息。
函数的规则
- 小。
- 做一件事。
- 使用描述性名称。
- 更喜欢更少的参数。
- 没有副作用。
- 不要使用标志(flag)参数。将方法分割成几个独立的方法，这些方法可以在没有标志的情况下从客户端调用。
注释规则
- 总是试着用代码来自我解释。
- 不要冗余。
- 不要添加明显的杂音。
- 不要使用闭合括号注释。
- 不注释掉代码。删除它。
- 用作意图的解释。
- 用于澄清代码。
- 用作对后果的警告。
源代码结构
- 纵向分离概念。
- 相关代码应该纵向密集展示。
- 变量的声明接近其使用处。
- 相关函数应该靠近。
- 类似的函数应该靠近。
- 将函数放置尾部后部。
- 保持代码行简短。
- 不要使用水平对齐。
- 使用空格来关联相关的事物和分离弱关联事物。
- 别破坏缩进结构。
对象和数据结构
- 隐藏内部结构。
- 尽量使用数据结构。
- 避免混合结构(半对象和半数据)。
- 越小越好。
- 做一件事。
- 少量的实例变量。
- 基类不应该知道它们的父类。
- 与其将一些代码传递给函数来选择一个行为，不如有许多函数。
- 推荐非静态方法胜过静态方法。
测试
- 一个测试一个断言。
- 可读。
- 快。
- 独立的。
- 可重复的。
代码异味
- 刚性。这个软件很难改变。一个小的变化会引起一系列后续的变化。
- 脆弱。由于一个单一的变化，软件在许多地方导致故障。
- 不动。由于涉及风险和高工作量，您不能在其他项目中重用部分代码。
- 不必要的复杂性。
- 不必要的重复。
- 不透明度。代码很难理解。
你的反应是：