译 | Robert C. Martin《clean code》总结

|


如果代码可以被团队中的每个人轻松理解，那么它就是整洁的。除了原始作者之外，其它开发人员也可以阅读和改进整洁的代码。可理解性带来了可读性、可修改性、可扩展性和可维护性。

一般规则

  1. 遵守标准约定。
  2. 保持简单愚蠢。越简单越好。尽可能减少复杂性。
  3. 童子军的规则。让营地比你想象的更干净。
  4. 一定要找到根本原因。总是寻找问题的根本原因。

设计规则

  1. 保持高水平的数据可配置。
  2. 与if/else或switch/case相比，有限使用多态。
  3. 分离多线程代码
  4. 防止过度配置
  5. 使用依赖注入。
  6. 迪米特法则。一个类应该只知道它的直接依赖项。

可理解性的建议

  1. 一致性。如果你以某种方式做某事，用同样的方式做所有类似的事情。
  2. 使用解释性变量。
  3. 封装边界条件。边界条件很难追踪。把它们的处理放在一个地方。
  4. 与原始类型相比，优先使用专用的值对象。
  5. 避免逻辑依赖关系。不要让一个方法的正确性取决于同一类中的其他内容。
  6. 避免反向条件。

命名规则

  1. 选择描述性和明确的名称。
  2. 做有意义的区别。
  3. 使用好叫的名字。
  4. 使用好搜索的名称。
  5. 用命名常量替换魔法数字。
  6. 避免编码(encoding)。不要添加前缀或类型信息。

函数的规则

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

注释规则

  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. 不透明度。代码很难理解。

英文原文：Summary of ‘Clean code’ by Robert C. Martin

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注