《C++编程规范——101条规则、准则与最佳实践》笔记009

C++编程规范

C++ coding standards

Author
Herb Sutter 《Exceptional C++ Style》 《Exceptional C++》 《More Exceptional C++》
Andrei Alexandrescu 《Modern C++ Design》 Loki

设计风格（适用面比一个特定的类或者函数更广的原则和实践）

复杂性啊，愚人对你视而不见，实干家受你所累。有些人避而远之。惟智者能够善加消除。 ——Alan Perlis

---

我知道，但是却又忘记了Hoare的至理名言：不成熟的优化是程序设计中的万恶之源。 ——Donald Knuth

简单和清晰之间的平衡、避免不成熟的优化、避免不成熟的劣化，不仅适用于函数编写的层次，而且适用于类和模块设计权衡的更大范围，适用于更深的应用程序架构决策。

依赖性管理是软件工程的一个基础，任意选择一个优秀的软件工程技术，无论选择哪一个，它都是在想尽办法减少依赖性。

• 继承？是为了使所编写的代码使用不依赖于实际派生类的基类。
• 尽量减少全局变量？是为了减少因可见范围太大的数据所产生的远距离依赖。
• 抽象？是为了消除处理概念的代码和实现它们的代码之间的依赖。
• 信息隐藏？是为了使客户代码不依赖实体的实现细节。

依赖性管理的一个相关问题还反映在避免使用共享状态中，反映在应用信息隐藏，以及其他之中。

最有价值：第6条——正确、简单和清晰第一。

第9条 不要进行不成熟的劣化

摘要

放松自己，轻松编程：在所有其他事情特别是代码复杂性和可读性都相同的情况下，一些高效的设计模式和编程惯用法会从你的指尖自然流出，而且不会比悲观的替代方案更难写。这并不是不成熟的优化，而是避免不必要的劣化（pessimization）。

讨论

避免不成熟的优化并不意味着必然损害性能。所谓不成熟的劣化，指的是编写没有必要的、可能比较低效的程序：

• 在可以通过引用传递的时候，却定义了通过值传递的参数。
• 在使用前缀++操作符很合适的场合，却使用后缀版本。
• 在构造函数中使用赋值操作而不是初始化列表。

如果减少对象的伪临时副本（尤其是在内循环中）并不影响代码的复杂性，那么这个优化就算不上不成熟的优化。在第18条中，提倡尽可能将变量声明为局部的，但是有时候将变量从循环中提出来是有好处的。大多数时候，这一点不会混淆代码的意图，相反，实际上这有助于澄清循环内部执行了哪些功能，哪些计算是不随循环变化的。当然，应该优先使用算法，而不是显式的循环。

构造既清晰又有效的程序：使用抽象和库。使用库的好处是，不仅能使代码更加清晰，更容易理解，而且启动也经常更快。

避免不成熟的劣化在编写库的时候尤其重要。要了解库所使用的所有上下文，通常是不可能的，因此可能需要达到一种平衡，在更加倾向效率和可复用性的同时，又不能因为一小部分潜在的调用者的利益过分提高效率。其中的界限要自己来划定，正如第7条，更需要关注的是可伸缩性，而不是挤掉一个小小的循环。