如果代码可以被团队中的每个人轻松理解，那么代码就是干净的。干净的代码可以由原作者以外的开发人员阅读和增强。可理解性带来了可读性、可更改性、可扩展性和可维护性。
一般规则

• 遵循标准约定。
• 保持简单愚蠢。越简单总是越好。尽可能降低复杂性。
• 童子军规则。让露营地比您发现时更干净。
• 始终找到根本原因。始终寻找问题的根本原因。

设计规则

1. 将可配置数据保持在较高水平。
2. 更喜欢多态而不是 if/else 或 switch/case。
3. 独立的多线程代码。
4. 防止过度配置。
5. 使用依赖注入。
6. 遵循德墨忒尔法则。一个类应该只知道它的直接依赖关系。

可理解性提示

1. 保持一致。如果你以某种方式做某事，那么所有类似的事情也以同样的方式做。
2. 使用解释变量。
3. 封装边界条件。边界条件很难跟踪。将它们的处理放在一个地方。
4. 优先选择专用值对象而不是原始类型。
5. 避免逻辑依赖。不要编写依赖于同一个类中其他内容而正确工作的方法。
6. 避免否定条件。

命名规则

1. 选择描述性且明确的名称。
2. 进行有意义的区分。
3. 使用可发音的名称。
4. 使用可搜索的名称。
5. 用命名常量替换幻数。
6. 避免编码。不要附加前缀或类型信息。

函数规则

1. 小。
2. 做一件事。
3. 使用描述性名称。
4. 喜欢更少的争论。
5. 没有副作用。
6. 不要使用标志参数。将方法拆分为几个独立的方法，这些方法可以在不带标志的情况下从客户端调用。

评论规则

1. 始终尝试用代码来解释自己。
2. 不要多余。
3. 不要添加明显的噪音。
4. 不要使用右大括号注释。
5. 不要注释掉代码。只需删除即可。
6. 用作意图解释。
7. 用作代码说明。
8. 用作后果警告。

源代码结构

1. 垂直分隔概念。
2. 相关代码应垂直密集显示。
3. 声明接近其用法的变量。
4. 依赖函数应该关闭。
5. 类似的功能应该很接近。
6. 将函数放在向下的方向。
7. 保持简短。
8. 不要使用水平对齐。
9. 使用空格来关联相关事物并分离弱相关事物。
10. 不要破坏缩进。

对象和数据结构

1. 隐藏内部结构。
2. 更喜欢数据结构。
3. 避免混合结构（一半对象和一半数据）。
4. 应该很小。
5. 做一件事。
6. 少量实例变量。
7. 基类应该对其派生类一无所知。
8. 拥有许多函数比将一些代码传递到函数中来选择行为更好。
9. 优先选择非静态方法而不是静态方法。

测试

1. 每个测试一个断言。
2. 可读。
3. 快。
4. 独立。
5. 可重复。

代码味道

1. 刚性。软件很难改变。一个小小的改变会导致一连串的后续改变。
2. 脆弱。由于一次更改，该软件在许多地方出现故障。
3. 一动不动。您无法在其他项目中重复使用部分代码，因为涉及风险和工作量。
4. 不必要的复杂性。
5. 无需重复。
6. 不透明度。代码很难理解。

我想的就这么多，但还有更多。
请阅读整本书。

感谢您阅读总结，希望对您有所帮助。

网站：
https://kaleemelahi.co

给我买一杯咖啡：
https://buymeacoffee.com/kaleemelahi