C++ Coding Standards:Summary of Summaries-组织和方针问题与设计风格

By Herb Sutter, Andrei Alexandrescu 著

树人 译

组织和方针问题

0.      不要为小事斤斤计较。（或者说是：知道什么东西不需要标准化）

少说废话，捡有必要的说：不要把个人的品味或废弃的实践强加于他人。

1.      在高警告级别下干净地编译代码。

要把警告放在心上：使用你的编译器的最高警告级别。要求干净（没有警告）的构建。理解所有的警告。通过修改你的代码来消除警告，而不是降低警告级别。

2.      使用自动构建系统。

触动单一的按钮：使用一个不需人工干预的构建整个工程的完全自动化（“单动作”）的构建系统。

3.      使用版本控制系统。

好记性不如烂笔头：使用版本控制系统（VCS）。永远不要让文件长时间地签出（check out）。在你通过更新的单元测试后，要经常性地签入（check in）。使得签入的代码不会破坏构建。

4.      投资于代码评审。

评审代码：人多力量大。向他人展示你的代码，阅读其他人的代码。大家都将受益。

设计风格

5.      一个实体一个内聚的责任。

一个时刻关注一件事情：赋予每个实体（变量，类，函数，名字空间，模块，库）一个定义明确的责任。随着实体的演化，其责任的作用域也随之加大，但其责任不能发散。

6.      正确性，简单性和清晰性是第一位的。

KISS（保持软件简单）：正确优于快速。简单优于复杂。清晰优于伶俐。安全优于不安全。（参见Item83和Item99）

7.      知道什么时候和如何为可伸缩性编码。

小心爆炸性的数据增长：不要过早地优化，着眼于渐进的复杂度。

对于作用于用户数据的算法，数据处理的复杂度应该是可预测的，最好是不比线性差。在证明了优化是有必要而且重要以后（特别是由数据量增加所引起的），应该集中于提高big-Oh复杂度，而不是作像少用一个额外的加法那样的优化。

8.      不要过早地优化。

无故加鞭（拉丁谚语Spur not a willing horse）：过早地优化是没有结果的,就像它很令人着迷一样。

优化的第一个原则是：不要去动它。优化的第二个原则（只对专家来说）是：还是不要去动它。衡量两次，优化一次。

9.      不要过早地悲观。

自己要轻松点，代码也是一样：在其他所有的情况都相同的情况下（尤其是代码复杂性和可读性），使用某个有效的设计模式和编码惯用法应该是你信手拈来的事，而且它不能比悲观的候选方法更难于编写。这并不是过早的优化；它是在避免没有必要的悲观。

10.  使全局和共享数据最少。

共享会引起争夺：避免共享数据，尤其是全局数据。共享数据会增加耦合性，它降低了可维护性，而且常常会降低效率。

11.  隐藏信息。

不要泄密：不要暴露一个提供了抽象的实体的内部信息。

12.  知道什么时候和如何为并行编码。

线程安全：如果你的应用程序使用了多线程或多进程，你就应该尽可能地减少共享对象（参见Item10），而且要安全地共享这些对象。

13.  保证资源被对象所拥有。使用显式的的RAII和智能指针。

当你有动力工具时，不要手工去锯：C++的“资源获取既是初始化”（RAII）惯用法是一个强大的正确的资源处理工具。RAII允许编译器提供强大而且自动化的保证，而在别的语言中这些保证需要脆弱的手工编写的惯用法来提供。在申请一块原始资源时，随即把它传递给一个固有的对象。绝不要在单一一个语句中申请多个资源。