Clean Code 代码检查清单

Posted 2021-01-24 abelzone

• 注释：
  • 不恰当的信息：注释只应该描述有关代码和设计的技术性信息。
  • 废弃的注释：过时、无关或不正确的注释就是废弃的注释。
  • 冗余注释：注释应该谈及代码自身没提到的东西
  • 糟糕的注释：值得编写的注释，也值得好好写。
  • 注释掉的代码
• 环境：
  • 需要多步才能实现的构建：构建系统应该是单步的小操作。
  • 需要多步才能做到的测试：应当能够发出单个指令就可以运行全部单元测试。能够运行全部测试是如此基础和重要，应该快速、轻易和直截了当地做到。
• 函数
  • 过多的参数，没参最好
  • 输出参数：输出参数就违反直觉。如果函数非要修改什么东西的状态不可，就修改它所在对象的状态好了。
  • 标识参数：布尔值参数大声宣告函数做了不止一件事。
  • 死函数：永不被调用的方法应该丢弃。别害怕删除函数。
• 一般性问题：
  • 一个源文件中存在多种语言：理想的源文件包括且只包括一种语言，应该尽力减少源文件中额外语言的数量和范围。
  • 明显的行为未被实现：最小惊异原则--函数或类应该实现其他程序员有理由期待的行为。
  • 不正确的边界行为：别依赖直觉。追索每种边界条件，并编写测试。
  • 忽视安全：关闭失败测试、告诉自己过后再处理，这和假装刷信用卡不用还钱一样坏。
  • 重复：核心原则。每次看到重复代码，都代表遗漏了抽象。
  • 在错误的抽象层级上的代码：只与细节实现有关的常量、变量或工具函数不应该在基类中出现。
  • 基类依赖于派生类：例外情况是派生类数量严格固定。
  • 信息过多：设计良好的模块有着非常小的接口，让你能事半功倍。设计良好的接口并不提供许多需要依靠的函数，所以耦合度也较低。设计低劣的接口提供大量你必须调用的的函数，耦合度较高。隐藏你的数据。隐藏你的工具函数。隐藏你的常量和你的临时变量。不要创建拥有大量方法或大量实体变量的类。不要为子类创建大量受保护变量和函数。尽量保持接口紧凑。通过限制信息来控制耦合度。
  • 死代码：死代码就是不执行的代码。
  • 垂直分隔：变量和函数应该在靠近被使用的地方定义。
  • 前后不一致：从一而终，小心选择约定，一旦选中，就小心持续遵循。
  • 混淆视听：
  • 人为耦合：不互相依赖的东西不该耦合。
  • 特性依恋：类的方法只应对其所属类中的变量和函数感兴趣，不该垂青其他类中的变量和函数。
  • “选择算子”参数：“选择算子”参数只是一种避免把大函数切分为多个小函数的偷懒做法。选择算子不一定是boolean类型，可能是枚举元素、整数或任何一种用于选择函数行为的参数。
  • 晦涩的意图：代码要尽可能具有表达力。
  • 位置错误的权责：软件开发者做出的最重要决定之一就是在哪里放代码。（最小惊异原则）代码应该放在读者自然而然期待它所在的地方。
  • 不恰当的静态方法：恰当的静态方法不应在单个实体上操作。
  • 应当使用解释性变量：让程序可读的最有力的方法之一就是将计算过程打散成在用有意义的单词命名的变量中放置的中间值。
  • 函数名称应该表达其行为：
  • 理解算法：“可以工作”是不行的，必须知道解决方案是正确的。
  • 应当把逻辑依赖改为物理依赖：依赖者模块不应对被依赖者模块有假定。
  • 应当用多态替代if/else或switch/case: 在使用if/else或switch/case前，先考虑使用多态。
  • 遵循标准约定：
  • 用命名常量替代魔术数：
  • 准确：
  • 结构甚于约定：坚守结构甚于约定的设计决策。命名约定很好，但却次于强制性的结构。
  • 封装条件：应该把解释了条件意图的函数抽离出来。
  • 避免否定性条件：
  • 函数只做一件事：
  • 不要掩蔽时序耦合：通过创建时序队列暴露时序耦合。
  • 应当封装边界条件：
  • 函数应当只在一个抽象层级上：（拆分不同抽象层级是重构的最重要的功能之一）
  • 应当在较高层级放置可配置数据
  • 避免传递浏览：确保模块只了解其直接协作者。
• Java
  • 通过使用通配符避免过长的导入清单：（这一项由IDE来实现）
  • 不要继承常量：
  • 常量 VS. 枚举 ：优先用枚举
  • 采用描述性名称：
  • 名称应与抽象层级相符
  • 尽可能使用标准命名法：
  • 无歧义的名称：
  • 避免编码：不应在名称中包括类型或作用范围信息。
  • 名称应该说明副作用：名称应该说明函数、变量或类的一切信息。
• 测试：
  • 测试不足：
  • 使用覆盖率工具：覆盖率工具能汇报你测试策略中的缺口。
  • 别略过小测试
  • 被忽略的测试就是对不确定事物的疑问：需求不明确而不能确定某个行为细节，可以用注释掉的测试或者用@Ignore标记的测试来表达我们对于需求的疑问。
  • 测试边界条件
  • 全面测试相近的缺陷
  • 测试失败的模式有启发性
  • 测试覆盖率的模式有启发性
  • 测试应该快速