本文是 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)的一种,因此修改后需要进行单元测试。