文档介绍：艿薆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条蒈尽可能局部地声明变量螂 避免作用域膨胀,对于需求如此,对于变量也是如此。变量将引入状态,而我