代码整洁之道
1. 名称
- 破窗理论，要保证每次合代码都比合之前更加clean，逐步进行重构。
- 起名字要尽可能直接地表达含义，采用有区分的准确的词汇而不是一些含义很宽泛的。
- 起名称避免思维映射，要直接熟悉。每个名词表达的含义要唯一，不可一会儿表达这个意思一会儿表达另一个意思。可以使用问题领域的专业词汇。
- 对于魔数要用常量进行定义。
2. 函数
- 函数体要尽可能短小，每个函数遵守“只做一件事”的原则，对于分支判断过多的场景（if/else, switch）的代码，可以考虑是否可以用策略模式实现。
- 注意控制单个函数的复杂度，可以利用圈复杂度检测工具来进行辅助。
- 函数名称要尽可能具有描述性，这比对这个函数添加注释要好很多。（而且注释会非常容易过时，腐坏）
- 函数参数要尽可能少，bool类型的参数警惕使用，返回值类型的参数要谨慎。
- 对于C++而言，如果满足const的条件要尽可能使用const，比如参数，函数。对于重写虚函数的要加override让编译器检查。
- 重复是邪恶的根源，要避免CV，如果发现要重复，说明有一些抽象的层次没有发现，需要利用语言的机制来去除这种重复
- 抽象子类
- 抽象方法
- 多态
- 模板
- 类型擦除
- 写代码一般不太可能一次写的就足够clean，可以先随心所欲地实现，然后再逐步地打磨它，分解函数，修改名称，消除重复，一次clean没什么人做得到。
- 写代码是一个讲故事的过程，就跟做presentation一样，可以多从读者的角度考虑，当别人第一次看到这份代码的时候，他们的感受是怎样的。
3. 注释
- 注释是很容易腐朽过期的，而且陈旧的，提供错误信息的注释比没有注释更可怕。
- 要尽可能少用注释，想办法通过提升命名，扩展代码的抽象层次来提高可读性。
- 需要的好的注释：
- 某些深奥的数据结构和算法等，可以添加一些注释进行说明。
- 对意图的解释。对于一些不太符合常规意图的操作，可以增加一些注释进行解释。
- 警示信息。某些代码的修改可能会导致其他比较远的模块的问题，但是又不太容易看出来。可以增加警示信息。（但出现这种情况是不是本身就表明了设计存在一些问题呢？）
- TODO。可以做的一些优化但是现在没有做的，增加TODO注释给未来提示。
- 坏注释：
- 自言自语，毫无信息量，多余的注释。比如为了自动生成文档而增加的注释。
- 注释掉的代码。删除吧，需要的时候版本管理工具会让我们找回它。
4. 格式
- 整个团队要保持格式的一致性，C++可以使用一份公用的
.clang-format,code review之前可以做强制格式检查。 - 垂直距离
- 函数内变量声明要尽可能靠近其使用的位置。
- 类成员要注意布局，按照相关性进行分类，在垂直分布上要能够体现出来，而不是全部揉成一坨。
- 相关函数要定义在一起。调用者要尽可能放到被调用者上面，而且两者距离不要太远。
- 概念相关的代码应该放到一起，相关性越强，彼此之间的距离就应该越近。
5. 边界
- 依赖的第三方库，操作系统接口等最后抽象出内部的接口，而不是直接讲起传播到整个系统内部。
- 对于依赖的其他模块还没有开发出来的代码，抽象出接口，然后依赖抽象，并自己实现一个mock的模块，之后再替换成真是的其他模块。如果抽象和真实的模块直接不是直接适配，可以使用Adapter模式进行处理。
6. 测试
- 保持测试代码的整洁，测试代码和生产代码一样重要。
测试的主要目的之一就是通过实例起到文档的作用。 - 测试使得改动成为可能，将历史发现的bug通过测试进行维护。每次合代码都需要通过全部测试。
- 每个测试分为清晰的BUILD-OPERATE-CHECK模式。
- 测试应该遵循的标准：
- 快速，支持频繁的运行
- 独立
- 可重复（一些不稳定的接口，比如获取当前时间，可以通过一些mock的方式进行处理）
- 自足验证，不应该通过看日志、手工比对两个文件的方式来确认测试是否通过。
- 及时。
- 测试保证和增强了生产代码的可扩展性、可维护性、可复用性。测试代码腐坏，那么省长代码也会跟着腐坏。
7. 跌进
- 运行所有测试
- 不可重复
- 表达程序员意图。
能写出工作的代码只是第一步，后续还需要花足够的时间去打磨。 - 尽可能减少类和方法的数量
