《C++编程规范：101条规则、准则与最佳实践》，原名《C++ Coding Standards: 101 Rules, Guidelines, and Best Practices》，作者：【美】Herb Sutter、【美】Andrei Alexandrescu，翻译：刘基诚，出版社：人民邮电出版社，ISBN：711514205X。本书是为 PDF 格式，影印版，大小 36MB，带有书签，方便读者朋友阅读。 *****荣获2005年JOLT生产效率大奖!***** *****本书作者，两位全世界最受尊敬的 C++ 专家将全球 C++ 社区的集体智慧和经验凝结成一整套编程规范。这些规范可以作为每一个开发团队制定实际开发规范的基础，更是每一位 C++ 程序员应该遵循的行事准则。***** 内容简介： 　　在本书中，两位知名的c++专家将全球c++界的集体智慧和经验凝结成一套编程规范。这些规范可以作为每一个开发团队制定实际开发规范的基础，更是每一位c++程序员应该遵循的行事准则。书中对每一条规范都给出了精确的描述，并辅以实例说明；从类型定义到错误处理，都给出了最佳的c++实践。即使使用c++多年的程序员也会从本书中受益匪浅。 　　 本书适合于各层次c++程序员使用，也可作为高等院校c++课程的教学参考书。 　　 良好的编程规范可以改善软件质量，缩短上市时间，提升团队效率，简化维护工作。在本书中，两位全世界最受尊敬的c++专家将全球c++界的集体智慧和经验凝结成一整套编程规范。这些规范可以作为每一个开发团队制定实际开发规范的基础，更是每一位c++程序员应该遵循的行事准则。. 　　 本书涵盖了c++程序设计的方方面面，包括设计和编码风格、函数、操作符、类的设计、继承、构造与析构、赋值、名字空间、模块、模板、泛型、异常、stl容器和算法等。书中对每一条规范都给出了言简意赅的叙述，并辅以实例说明；书中还给出了从类型定义到错误处理等方面大量的c++最佳实践，包括许多最新总结出的和标准化的技术，即使使用c++多年的程序员也会从中受益匪浅。 　　 ■通过阅读本书，可以找到以下问题的答案：.. 　　 ■哪些东西值得标准化?哪些东西不值得标准化? 　　 ■使代码可扩展的最佳方法是什么? 　　 ■合理的错误处理策略有哪些要素? 　　 ■如何(和为什么要)避免不必要的初始化、循环依赖和定义依赖? 　　 ■何时应该(以及如何)同时使用静态和动态的多态性? 　　 ■如何实践“安全的”改写(override)? 　　 ■何时该提供不会失败的交换(swap)? 　　 ■为什么要阻止异常跨越模块边界传播?如何阻止? 　　 ■为什么不应该在头文件中写名字空间声明或指令? 　　 ■为什么应该使用stl vector和string代替数组? 　　 ■如何选择正确的stl搜索算法? 　　 ■为了保证代码的类型安全，应该遵从哪些规则?... 目录： 前 言 组织和策略问题 1 第0条　不要拘泥于小节（又名：了解哪些东西不应该标准化） 2 第1条　在高警告级别干净利落地进行编译 4 第2条　使用自动构建系统 7 第3条　使用版本控制系统 8 第4条　在代码审查上投入 9 设计风格 11 第5条　一个实体应该只有一个紧凑的职责 12 第6条　正确、简单和清晰第一 13 第7条　编程中应知道何时和如何考虑可伸缩性 14 第8条　不要进行不成熟的优化 16 第9条　不要进行不成熟的劣化 18 第10条　尽量减少全局和共享数据 19 第11条　隐藏信息 20 第12条　懂得何时和如何进行并发性编程 21 第13条　确保资源为对象所拥有。使用显式的raii和智能指针 24 编程风格 27 第14条　宁要编译时和连接时错误，也不要运行时错误 28 第15条　积极使用const 30 .第16条　避免使用宏 32 第17条　避免使用“魔数” 34 第18条　尽可能局部地声明变量 35 第19条　总是初始化变量 36 第20条　避免函数过长，避免嵌套过深 38 第21条　避免跨编译单元的初始化依赖 39 第22条　尽量减少定义性依赖。避免循环依赖 40 第23条　头文件应该自给自足 42 第24条　总是编写内部#include保护符，决不要编写外部#include保护符 43 函数与操作符 45 第25条　正确地选择通过值、（智能）指针或者引用传递参数 46 第26条　保持重载操作符的自然语义 47 第27条　优先使用算术操作符和赋值操作符的标准形式 48 第28条　优先使用++和- -的标准形式。优先调用前缀形式 50 第29条　考虑重载以避免隐含类型转换 51 第30条　避免重载&&、
版权声明 Authorized translation from the English language edition, entitled C++ Coding Standards 1OI Rules, Guidelines, and Best Practices, 1st Edition 0321113586 by Herb Sutter and Andrei Alexandrescu, published by pearson Education, Inc, publishing as Addison- Wesley Professional, Copyright o 2005 Pearson Education, Inc All rights rescrved. No part of this book may bc reproduced or transmittd in amy form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc CHINESE SIMPLIFIED edition published by PEARSON EDUCAtiONAslaLtD and POSTS TELECOm Press Copyright C 2006 本书中文简体字版由 Pearson education asia ltd授权人民邮电出版社独家出版。未经出 版考书面许可,不得以任何方式复制或抄袭本书内容。 书封面贴有 Pearson education(培生教育出版集团)激光防伪标签,无标签者不得锵售 版权所有,侵权必究。 前言 尽早进入正轨:以同样的方式实施同样的过程。不断积累惯用法。 将其标准化。如此,你与莎士比亚之间的惟一区别将只是掌握 员用法的多少一而非词汇的多少。 Alan perlis 标准最大的优点在于,它提供了如此多样的选择。 出处尚无定论 我们之所以编写本书,作为各开发团队编程规范的基础,有下面两个主要原因: ·编程规范应该反映业界最久经考验的经验:它应该包含凝聚了经验和对语言的深刻理解 的公认的惯用法。具体而言,编程规范应该牢固地建立在大量丰富的软件开发文献的基 础之上,把散布在各种来源的规则、准则和最佳实践汇集在一起。 不可能存在真空状态:通常,如果你不能有意识地制定合理的规则,那么就会有其他人 推行他们自己喜欢的规则集。这样产生的编程规范往往具有各种最不应该出现的属性 例如,许多这样的编程规范都试图强制尽量少地按C语言的方式使用C++。 许多糟糕的编程规范都是由一些没有很好地理解语言、没有很好地理解软件开发或者试图标 准化过多东西的人制定的。糟糕的编程规范会很快丧失可信度,如果程序员不喜欢或者不同意其 中一些糟糕的准则,那么即使规范中有一些合理的准则,也可能被不抱幻想的程序员所忽略,这 还是最好的情况——最坏的情况下,糟糕的标准可能真地会被强制执行。 Alan perlis(1922-1990)“因为在高级程序设计技术和编译器构造领域的影响”而获得1966年首届图 灵奖。他是影响深远的计算机科学先驱之一,曾担任 ALGOL语言设计委员会主席,倡议创办了 Communications of ACM杂志并担任首任主编,对计算机成为独立学科起到了关键性的作用。1982年他 在 SIGPLAN杂志上发表的“ Epigrams in Programming”(编程格言)一文,由130条格言组成,凝练隽 永,多年来一直被广泛引用,本书亦然。一译者注 2前言 如何使用本书 三思而行。应该认真地遵循好的准则,但是不要盲从。在本书的各条+,请注意“例外情况” 部分阐明了该准则可能不量用的不太常见的情况。任何拌则,无论如何正确(当然,我们自认为 本弓中的准则是正的),都不能代替自已的思考。 每个开发团队都应该制定自己的标准,制定标准的时候都应该尽职尽贲。这项工作是整个团 队的事情。如果你是团队负责人,应该让团队成员都参与制定标准;人们当然更紧意遵守“自 的”标准,前非感觉是别人强加的堆规矩 编写本书的日的是为各开发囡队提供编程规范的基础和参孝。它并不是要成为终极编程规 范;因为不同的团队会有适合特定群体或者特定任务的更多准则,应该大胆地将这些准则加入本 书的条款中。但是我们希望本|能够通过记载和引汨广泛接受的、权威的、几乎可以通月的“例 外情况”指出的除外〕实战经验,减少读者制定或重新制定自己的编程规范的工作量,从而帮助 提高读者所用编程姚范的质量和一致性。 让团队人员阅读这些准则及共原理阐释(也就是本书全文,根据需要还包括所选条款引用的 其他书籍和论文),共同决定是否有困队根个无法接受的内容(比如,于茉些项日特殊的情况), 然后实践其佘规范。一采纳,则在未与整个团队协商的情况下,任何人不得违反团队编程规范。 最后,圳队还需定期复查这些准则,加入来自实际应用中的经验和反馈 编程规范与人的关系 好的编程规氾能够带来下列许多杓可关联的优点 改善代码质量:鼓勋开发人员贯地正确行事,从而能够直接提高软件的质量和可维 护性。 ·提高开发速度:开发人员不需要总是从一些基本原则出发进行决策。 增进团队精神:有助丁减少在此小事卜不必要的争论,使团队成员更容易阅读和维护 其他成员的代码 在正确的方向上取得一致:使开发人员放开于脚,在有意义的方向上发挥刨造性 在压力和时间的要求下,人的将按所受到的训练行事。他们会求助于习惯。这正是医院的 急诊室之所以要雇佣有经验的、训练有素的人员的原因所在,知识再渊博约新手到时候也会手足 无拮。 仵为软件开发人员,我们总是面对若巨大的E力,“明大的软件昨大就应该交付了”。在进度 压力下,我们安所受到的训练和惯工作。平时不知道敦件工程良好实践的(或者习惯应用这 些实践的)马虎程序员,在压力下将編写出更加马虎、错误更多的代码。相反,养成良好巧惯并 经常按此工作的程序员将保持自已的纠织性,快速提交高质量的代码 前 本书所介绍的编程规范是隻编写扃质量C+代码准则之大成。它们是C+社区丰富集体经验 旳精华总结。这知认体系中的大量内容,此前要么只能零苓碎碎地从不同的书屮找到,要么斋 要依靠口口相传。编写本书的H的就是要将这些知识收集起来,汇成一组简练合理、易予坦解 容易实施的规则。 当然,即使有最佳编栏规范,还是有人会编写出糟糕的代码。任何语言、过程或者方法皆然 但是,好的编程规范集能够培荞超越规则不身的良好习惯和纪律。这种基础一打好,就将打开 通往更高层次的人门。这里没冇捷径可走:在学会写诗之前必须肖先扩大词汇量,熟悉语沄。我 们只希望本书能够对读者所经历的这一过程所裨益 我们希望本书适用于各种层次的C++程序员 如果你是初级程序员我们希望你能够发现,这些规则及其原理阐释有助于理解C+言对 哪些风格和惯用法的攴持最为自然。我们为每·规则和准则都提供∫简洁的原理阐释和讨论,这 是为了鼓励你重在理解,而不是死记硬背。 对于中级或者级程序员,我们下∫很大功大为每…规则都提供了详细的准确引用列袤。这 样,你就能够对规则在C+类型系统、请法和对象模型中的来历作进一步的研究。 无论如何,你很可能丁作在一个复杂项目的团队屮。这正是编程规范的用武之地——你可以 使用这些规范将团队统一提高到同一层次,并为代码审查打下基础。 关于本书 我们为本书制定了以设计目标: ·一寸短,一寸強:篇幅极大的编程规范很难被人接受,而短小精怍的才会有人阅读和使 用。同样,长的条款容易被人忽视,而短的条款才会被阅读和使用。 ·每个条款都必須是无可争议的:本书的目的是为了记载已达成广泛共识的标胜,而不是 凭空发明一些規范。如果有什么准则并非在所有情况下都适用,我们会明确指出(比如 用“考虑……”而不是“应该……”来表示),并提供普避接受的例外情况。 每个条款都必须具有权威性:本书中的准则均引用比出版著作作为支持。编写本书的目 的也包括提供C+文献的索引。 ◆毎个条款都必須有阐述的价:我们不为肯定会做的事情比如编译器已纤强制要求或 者检查的事情)或者其他条款匚经涵盖的事情定义准则。 例如,“不要返回自动变量的指针用”是一个不铠的准则,但是我们没有将它放在本书中, 因为我们测试过的所有编译器都会对此发出警告,所以这一何题已经涵盖在吏广的第条“在高 警告级别T净利落地进行编译”中了 例如,“使用编辑器〔或者编译器,或者调试器)”是一个不错的准则,但是你当然会使用这 4前言 些⊥具,这是不言自明的;与此相反,我们前四个条款中有两个是关于其他工具的:“使用白动 构建系统”和“使用版本控制系统”。 例如,“不要滥got语句”是一个很好的条款,但是根鋸我们的经验,程序员普遍都知道 这点,所以对此毋甯我们多言 每个条款都遵照下面的格式 杀款标题:最简单爪又意味深的“原者重现”,有助于更好地记忆规则。 摘要;最核心的要点,简要陈述 讨论:刘准则的展开说明。通常似括对原瓔为筒要阐释,但是请记住,原理阐释的三要 部分都勻意识地宦在参考文献中了。 ●示例(可选):说明姚则或者冇助于记忆规郧的实例。 憮外情况(可选}规则不适压的仨何(通常是比较罕见的)情况。但是要小心,不要掉 入过匆忙不加思考的陷阱:“噢,我很特垛,所以这条规则对我的情况并不适用” 这种推理很常见,但是通常郁是错的 参考文献;可以参考其中提到的C+4文献的节,进而获得完整的细节和分析。 每“剖分中,我们都会选拌挥荐*个“最有价值条款”。通常,它是该部分中的第一个条款, 因为我们尽量将重要的条款放仁每-部分的前面。但是有时候,出于连贯和可读性的考虑,我们 不能将重要的条款前置,因此需要釆取这样的办法突出它们,以引起特別注意。 致谢 非常感谢丛书主编 Bjarne Stroustrup、本书的编辑Per( Gordon和 ebhie Lafferty,有 Tyre! Albaugh、 Kim boedigheimer、 John fulter、 Bernard gaffney、 Curt johnson、 Chanda Leary-CoutLE、 Charles leddy、 Heather mullane、 Chuti prasertsith、 Lara wysong,以及 Addison-Wesley 囝队的其他成员,感谢他们在本写作过程中给予的协助和坚持。和他们·起工作确实是…一种菜 各条款标题中“原音现”的灵感有许多米源,包折江Ce9幽默风格和[ Peters9中经典 的“ import this”,还有传奇般的A! an perlis和他被广为引用的杰出格言。 我们特別想感谢在本书技术审阅方面做出贡献的人,他们的工作使本书许多部分增色不少。 从选題开始直到最终成稿,丛书主编 Bjarne Strout所提出的尖锐而又透彻的意见对本书影响 全探。我们要特別感谢 Daye abraham、 Marshall cline、 Kevlin Henney、 howard hinnant、Jin Hyslop、 Nicolai josuttis Jon Kalb, Max khesar、 Stan lippman、 Scott Meyers和 Daveed vandevoorde 1.指 Addison-wes!ey公司出版的著名的C→+Im-pth"丛书包括 Essenti C++ accelerated++、 Exception!C+ MkmC++Des等,并已在内引进H版 译注 前言5 积极参与审阋,并对原稿多个版木的草稿都提出详细的意见。其他有价值的意见和反馈要归功 于 Chuck allison、 Samir bajaj、 Marc barbour、 Damian dechen、 Steve dewhurst、 Peter dimon、 Alan griffiths. Michi henning、 James kanze、Ma!Mau、 Petru Marginean、 Robert o.“ Uncle bob Martin、 letf peil, Peter pirkelbauer、 ladimir prus、 Dan saks、 Luke Wagner、 Matthew wilson和 Leor zolman。 与往常一样,书中衍然会存在错误、疏漏利含混之处,这些都是我付作者的责任 Herb Sutter Andrei alexandrescu 2004年9几 于美国华盛顿州西雅图市 目录 组织和策略问题 第0条不要拘泥于小节!又名:了解哪些东严不应该标准化) 第1条在高警告级别干净利落地进行编译…… T『■ 第2条使用日动构建系统 247o 第3条使用版木控制系统… 第4条在代码审查上投入…………… 设计风恪 甲甲■■■ 第5条一个实体应该只有一个紧凑的职责 hq如 第6条‖确、简单和清晰第 ■■■■■平P■■■■■中■·?P■會中国■甲平■ 第7条編程中应知道何时和如何考虑可伸缩性 14 第8条不要进行个成熟的优化 第9条不要进行不成熟的劣化… 8 第t0条尽量减少全局和共享数据…………………… 19 第11条隐威信息… ■■■■■■■■■■■■■■■■晶■■司■■■■昌■■■■■■司■■■■■驷■■罪唱■■■罩■+4lm■↓l4lbl ■■■L止↓晶■■ 第]2条懂得何时和如何进行并发性编程 自■■■■■目“申血■目目會自目■■■■會自q目目■■晶 1■■■■■ 13条确保资源为对象所杋有。使显式的RA∏和智能指针……-24 编程风格 ■ ■■画』』·a·昌山山■d山。·LLL·daa■山L 7 第14条宁要编译时和连接时借误,也不要运行时错误……… 28 第15条积极使用 const 第16条避免使用宏 平平■■t nnmm■ 32 第17条避兔使用“魔数 冒冒 iI 第]8条尽可能局部地声明变量 第19条总是初始化变量 I■■■■p 卩■■■■■↓↓■■■■↓■喝■啁口■罩■ 36 第20条避凭函数过长,避免嵌套过深………………… 38 2目录 第21条避免跨编译单元的初始化依赖…… 第22条·尽量缄少定义性依赖。避免循环赖 第23条头文件应该自给自足 42 第24条总是编写内部# nclude侏护符,决不要编写外部# include保护符………43 网数与操作符 q■■■日■■ ……………45 鹤25条F确地选择通过值、(智能)指钅或者引用传递参数……… 46 第26条倸持重载操作符的自然语义 47 第27条少先使用算术操作符和赋值操作符的标准形式… 48 第28条优先便用++和-的标准形式。优先调用前缀形式 ■l■■L4■blb如■ldLp 50 第29条考虑重载以避免隐含类型转换………… 第30条过免重载&&、||或,(返号)………………52 第31条不要纳写依籹于函数参数求值顺序的代码 类的设计与继承… B4.14 第32条弄清所要编写的是哪种类 第33条用小类代替巨类 57 第34怒用红合代替继承 香■■■■ ……58 第35条避免从并非要没计成基类的类口继承 第36条优先提供抽象妾凵 ■■■■■■■中會· ll■·q自1P ■P■忄 Id自冒■国會中■會咱■■■自■自■會口T■■鲁中■目国自冒■ 62 第37条会用继意即可替换性。丝承,不是为了重用,而是为了被重用… 第38条实施安全的改零 算39条考虑将虚拟函数声明为非公用的,将公用数声明为非虚拟的………68 笃40条要避免提供隐式转换 第41条将数据成员设为私有的,无行为的樂集(C语言形式的stu)除外……72 第42条婆公内部数据 ■■十■■旷晋■■■b蚤古■■■旷十俨■■b量b■■■■■■■+ 74 第43条智地使用Pmpl 第4条优先编写非成员非友八函数…… 79 第45条总是一起提供new和deee………………………………80 第46条如果提供类专门的new,应该提供所有标准形式(普通、就地和不抛出)…82 构造、析构与复制 第47条以回样的顺序定义和初始化成员变量……… …86 第48条在构造函数屮用初始化代替赋值 ■平Pl■l『自』bI『ll鲁中l_rP平llP自鲁自■冒■d■會中咱■ 87 第49条避兔在构造函数和析构函数中调用虚拟函数