Go 代码整洁之道
目录
干净的代码能够被团队中的每个成员轻松理解。干净的代码可以被原作者之外的开发者阅读和增强。伴随着可理解性而来的，是可读性、可变更性、可扩展性和可维护性。
通用规则
- 遵循标准约定。
- KISS原则（保持简单直接）。越简单总是越好。尽可能减少复杂性。
- 童子军规则。让营地比你发现时更干净。
- 始终找到根本原因。始终寻找问题的根源。
设计规则
- 将可配置数据放在较高层级。
- 优先使用多态而非 if/else 或 switch/case。
- 分离多线程代码。
- 防止过度配置。
- 使用依赖注入。
- 遵循德米特法则。一个类应该只了解它的直接依赖。
提高可理解性的技巧
- 保持一致性。如果你以某种方式做某事，那么所有类似的事情都以相同的方式做。
- 使用解释性的变量。
- 封装边界条件。边界条件很难跟踪。将它们相关的处理放在一个地方。
- 优先使用专用的值对象而非原始类型。
- 避免逻辑依赖。不要编写那些正确运行依赖于同一类中其他内容的方法。
- 避免否定性的条件判断。
命名规则
- 选择描述性强且无歧义的名称。
- 做出有意义的区分。
- 使用可读的名称。
- 使用可搜索的名称。
- 用命名常量替换魔法数字。
- 避免编码。不要添加前缀或类型信息。
函数规则
- 要小。
- 只做一件事。
- 使用描述性的名称。
- 参数越少越好。
- 无副作用。
- 不要使用标记参数。将方法拆分为几个独立的方法，客户端可以无需标记直接调用。
注释规则
- 始终尝试用代码解释自己。
- 不要画蛇添足。
- 不要添加明显的噪音。
- 不要使用右大括号注释。
- 不要注释掉代码。直接删除。
- 用注释解释意图。
- 用注释澄清代码。
- 用注释警示后果。
源代码结构
- 垂直方向分离概念。
- 相关的代码在垂直方向上应该紧凑出现。
- 在靠近使用位置声明变量。
- 相互依赖的函数应该靠近。
- 相似的函数应该靠近。
- 函数调用方向应该向下。
- 保持行短小。
- 不要使用水平对齐。
- 使用空白关联紧密相关的内容，分离弱相关的内容。
- 不要破坏缩进。
对象与数据结构
- 隐藏内部结构。
- 优先使用数据结构。
- 避免混合结构（半对象半数据结构）。
- 应该短小。
- 只做一件事。
- 减少实例变量的数量。
- 基类不应了解其派生类。
- 与其将代码传递到函数中选择行为，不如拥有许多函数。
- 优先使用非静态方法而非静态方法。
测试
- 每个测试一个断言。
- 可读的。
- 快速的。
- 独立的。
- 可重复的。
代码异味
- 僵化性。软件难以改变。一个小小的修改会导致一连串的后续修改。
- 脆弱性。软件因一个单一的修改而在多处崩溃。
- 牢固性。由于涉及的风险和高成本，你无法在其他项目中重用部分代码。
- 不必要的复杂性。
- 不必要的重复。
- 晦涩性。代码难以理解。