本文是 Clean C++ by Stephan Roth 的读书笔记。
KISS
“Keep it simple, stupid” / “Keep it simple and stupid”.
在能实现功能的前提下，尽量简洁。
好处：不会加入不必要的代码而使得其复杂化。
YAGNI
“You Aren’t Gonna Need It!”.
不要写那些当下用不到而未来可能用到的代码。
好处：拒绝无用功。
注意：即使未来用到的时候，用代码重构（Refactoring）解决。
DRY
“Don’t repeat yourself!”
不要重复一段代码。
好处：更改代码的时候只需要更改一处。
Information Hiding
代码 A 调用代码 B 时，不必知道 B 的内部实现机制。
好处：更改代码 B 的内部实现时，代码 A 无感。
Strong Cohesion
每个模块完成一个定义明确的任务。
好处：若每个模块完成多个（彼此相关性很差）的任务，模块间依赖关系会非常复杂，代码维护和测试会非常困难；若一个逻辑概念的实现分散在多个模块内，也会产生过多的依赖（甚至循环依赖）。
Loose Coupling
一个模块不能直接调用另一个模块，要利用接口（Interfaces）实现模块间的交互。在 C++ 等预压中，接口可以由一个抽象的父类实现。
好处：一个类的实现完全与其他实类脱钩；写一个从抽象父类继承的模拟（mock）测试模块，可以单独测试；如果需要延申功能，只需要从抽象父类继承创建一个新类。
Be Careful with Optimizations
除非不能满足明确的业务需求，否则不要进行性能的优化。
好处：维持代码可读性和可维护性，参见 YAGNI 原则。
Principle of Least Astonishment (PLA)
沿用惯例，不要标新立异创造违反第一直觉的交互方式。
好处：让用户可以预知操作的结果，能立刻明白提示信息等。
The Boy Scout Rule
当发现代码片段有原则上的错误时，立刻修正。比如，规范对象命名，将冗长的函数拆解，去掉不必要的注释并修缮代码使其本身显而易见，去掉难以理解的逻辑判断语句，去除重复代码等。
好处：避免积重难返。
注意：修正属于代码重构（Refactoring）的一种，因此修改后需要进行单元测试。