如果代码可以被团队中的每个人轻松理解，那么代码就是干净的。干净的代码可以由原作者以外的开发人员阅读和增强。可理解性带来了可读性、可更改性、可扩展性和可维护性。
一般规则
- 遵循标准约定。
- 保持简单愚蠢。越简单总是越好。尽可能降低复杂性。
- 童子军规则。让露营地比您发现时更干净。
- 始终找到根本原因。始终寻找问题的根本原因。
设计规则
可理解性提示
- 保持一致。如果你以某种方式做某事，那么所有类似的事情也以同样的方式做。
- 使用解释变量。
- 封装边界条件。边界条件很难跟踪。将它们的处理放在一个地方。
- 优先选择专用值对象而不是原始类型。
- 避免逻辑依赖。不要编写依赖于同一个类中其他内容而正确工作的方法。
- 避免否定条件。
命名规则
- 选择描述性且明确的名称。
- 进行有意义的区分。
- 使用可发音的名称。
- 使用可搜索的名称。
- 用命名常量替换幻数。
- 避免编码。不要附加前缀或类型信息。
函数规则
- 小。
- 做一件事。
- 使用描述性名称。
- 喜欢更少的争论。
- 没有副作用。
- 不要使用标志参数。将方法拆分为几个独立的方法，这些方法可以在不带标志的情况下从客户端调用。
评论规则
- 始终尝试用代码来解释自己。
- 不要多余。
- 不要添加明显的噪音。
- 不要使用右大括号注释。
- 不要注释掉代码。只需删除即可。
- 用作意图解释。
- 用作代码说明。
- 用作后果警告。
源代码结构
- 垂直分隔概念。
- 相关代码应垂直密集显示。
- 声明接近其用法的变量。
- 依赖函数应该关闭。
- 类似的功能应该很接近。
- 将函数放在向下的方向。
- 保持简短。
- 不要使用水平对齐。
- 使用空格来关联相关事物并分离弱相关事物。
- 不要破坏缩进。
- 隐藏内部结构。
- 更喜欢数据结构。
- 避免混合结构（一半对象和一半数据）。
- 应该很小。
- 做一件事。
- 少量实例变量。
- 基类应该对其派生类一无所知。
- 拥有许多函数比将一些代码传递到函数中来选择行为更好。
- 优先选择非静态方法而不是静态方法。
测试
- 每个测试一个断言。
- 可读。
- 快。
- 独立。
- 可重复。
代码味道
- 刚性。软件很难改变。一个小小的改变会导致一连串的后续改变。
- 脆弱。由于一次更改，该软件在许多地方出现故障。
- 一动不动。您无法在其他项目中重复使用部分代码，因为涉及风险和工作量。
- 不必要的复杂性。
- 无需重复。
- 不透明度。代码很难理解。
我想的就这么多，但还有更多。
请阅读整本书。
感谢您阅读总结，希望对您有所帮助。
网站：
https://kaleemelahi.co
给我买一杯咖啡：
https://buymeacoffee.com/kaleemelahi
