(编程规.docVIP

C++编程规范： 第0条 不要拘泥与小节 只规定需要规定的事情：不要强制施加个人喜好或者过时的做法。有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编程的规范中。应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。 第1条 在高警告级别干净利落地进行编译 高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。成功的构建应该是没有警告的，如果不是这样，你很快就会养成不仔细查看输出的习惯，从而漏过真正的问题，因为良性警告的后面可能隐藏着未来指向真正危险的警告。 第2条 使用自动构建系统 一次案按键就解决问题：使用完全自动化(单操作)的构建系统，无限用户干预即可构建整个项目。 第4条 在代码审查上投入 审查代码：更多的关注有助于提供质量。亮出自己的代码，阅读别人的代码。互相学习彼此都会受益。 好的代码审查过程对开发团队有许多方面的益处，它能够 通过来自同伴的良性压力提高代码的质量 找出错误、不可移植的代码和潜在的扩展问题 通过思想交流获得更好的设计和实现 快速培养新同事和初入门者 在团队中形成共同的价值观和集体主义 增加整体实力，提升自信心、动力和职业荣誉感 第5条 一个实体应该只有一个紧凑的职责 一次只解决一个问题：只给一个实体（变量、类、函数、名称空间、模块和库）赋予一个定义良好的职责。随着实体变大，其职责范围自然也会扩大，但职责不应该发散。 第6条 正确、简短和清晰第一 软件简单为美：正确优于速度。简单优于复杂。清晰优于技巧。安全优于不安全。 第7条 编程中应该知道何时和如何考虑可伸缩性 小心数据的爆炸性增长：不要进行不成熟的优化，但是要密切关注渐进复杂性。处理用户数据的算法对所处理的数据量耗费的时间应该是可预测的，最好不差于线性关系。如果能够证明优化必要而且非常重要，尤其在数据量逐渐增长的情况下，那么应该集中精力改善算法的O(N)复杂性，而不是进行小型的优化，比如节省一个多余的家法运算。 第8条 不要进行不成熟的优化 快马无需鞭策：不成熟优化的诱惑非常大，而它的无效性也同样严重。优化第一原则就是：不要优化。优化的第二原则（仅适于于专家）是：还是不要优化。再三测试，而后优化。 第10条 尽量减少全局和共享数据 共享会导致冲突：避免共享数据，尤其是全局数据。共享数据会增加耦合度，从而降低可维护性，通常还会降低性能。 第11条 隐藏信息 不要泄密：不要公开提供抽象的实体的内部信息。为了尽量减少操作抽象的调用代码和抽象的实现之间的依赖性，必须隐藏实现内部的数据。否则，调用代码就能够访问——或者更糟，操作——该信息，而原本应属于内部的信息就泄漏给了调用代码所依赖的抽象。 第12条 懂得何时和如何进行并发性编程 如果应用程序使用了多个线程或者进程，应该知道如何尽量减少共享对象，以及如何安全地共享必须共享的对象。 第13条 确保资源为对象所拥有。使用显式的RALL和智能指针 C++的“资源获取即初始化”惯用法是正确处理资源的利器。RALL使编译器能够提供强大且自动的保证，这在其他语言中可能需要脆弱的手工编写的惯写法才能实现的。分配原始资源的时候，应该立即将其传递给属主对象。永远不要在一条语句中分配一个以上的资源。 第14条 宁要编译时和连接时错误，也不要允许时错误 能够在编译时做的事情，就不要推迟到运行时：编写代码时，应该在编译期间使用编译器检查不变式，而不应该在运行时在进行检查。运行时检查取决于控制流和数据的具体情况，这意味很难知道检查的是否彻底。相比而言，编译时检查与控制流和数据无关，一般情况下能够获得更高的可信度。 第15条 积极使用const const是我们地朋友：不变地值易于理解、跟踪和分析，所以应该尽可能地使用常量代替变量，定义值的时候，应该把const作为默认的选项：常量很安全，在编译时会对其进行检查，而且它与C++的类型系统已浑然一体。不要强制转换const的类型，除非要调用常量不正确的函数。 第16条 避免使用宏 宏是C和C++语言地抽象设施中最生硬的工具，它是披着函数的外衣的饥饿的狼，很难驯服，它会我行我素地游走于各地。要避免使用宏。 第17条 避免使用“魔数” 程序设计并非魔术，所以不要故弄玄虚：要避免在代码中使用诸如42和3014159这样地文字常量。它们本身没有提供任何说明，并且因为增加了难于检测地重复而使维护更加复杂，可以用符号名称和表达式来替换它们。 第18条 尽可能局部地声明变量 避免作用域膨胀，对于需求如此，对于变量也是如此。变量将引入状态，而