C++编程规范
出版社:人民邮电出版社
出版日期:2005-9
ISBN:9787115137708
作者:(美)萨特 亚历山德莱斯库
页数:220页
书籍目录
Organizational and Policy Issues 1
0. Don't sweat the small stuff. (Or: Know what not to standardize.) 2
1. Compile cleanly at high warning levels. 4
2. Use an automated build system. 7
3. Use a version control system. 8
4. Invest in code reviews. 9
Design Style 11
5. Give one entity one cohesive responsibility. 12
6. Correctness, simplicity, and clarity come first. 13
7. Know when and how to code for scalability. 14
8. Don't optimize prematurely. 16
9. Don't pessimize prematurely. 18
10. Minimize global and shared data. 19
11. Hide information. 20
12. Know when and how to code for concurrency. 21
13. Ensure resources are owned by objects. Use explicit RAII and smart pointers. 24
Coding Style 27
14. Prefer compile- and link-time errors to run-time errors. 28
15. Use const proactively. 30
16. Avoid macros. 32
17. Avoid magic numbers. 34
18. Declare variables as locally as possible. 35
19. Always initialize variables. 36
20. Avoid long functions. Avoid deep nesting. 38
21. Avoid initialization dependencies across compilation units. 39
22. Minimize definitional dependencies. Avoid cyclic dependencies. 40
23. Make header files self-sufficient. 42
24. Always write internal #include guards. Never write external #include guards. 43
Functions and Operators 45
25. Take parameters appropriately by value, (smart) pointer, or reference. 46
26. Preserve natural semantics for overloaded operators. 47
27. Prefer the canonical forms of arithmetic and assignment operators. 48
28. Prefer the canonical form of + + and --. Prefer calling the prefix forms. 50
29. Consider overloading to avoid implicit type conversions. 51
30. Avoid overloading &&, ￠ò, or, (comma). 52
31. Don't write code that depends on the order of evaluation of function arguments. 54
Class Design and Inheritance 55
32. Be clear what kind of class you' re writing. 56
33. Prefer minimal classes to monolithic classes. 57
34. Prefer composition to inheritance. 58
35. Avoid inheriting from classes that were not designed to be base classes. 60
36. Prefer providing abstract interfaces. 62
37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused 64
38. Practice safe overriding. 66
39. Consider making virtual functions nonpublic, and public functions nonvirtual. 68
40. Avoid providing implicit conversions. 70
41. Make data members private, except in behaviorless aggregates (C-style structs). 72
42. Don't give away your internals. 74
43. Pimpl judiciously. 76
44. Prefer writing nonmember nonfriend functions. 79
45. Always provide new and delete together. 80
46. If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow). 82
Construction, Destruction, and Copying 85
47. Define and initialize member variables in the same order. 86
48. Prefer initialization to assignment in constructors. 87
49. Avoid calling virtual functions in constructors and destructors. 88
50. Make base class destructors public and virtual, or protected and nonvirtual. 90
51. Destructors, deallocation, and swap never fail. 92
52. Copy and destroy consistently. 93
53. Explicitly enable or disable copying. 95
54. Avoid slicing. Consider Clone instead of copying in base classes. 96
55. Prefer the canonical form of assignment. 99
56. Whenever it makes sense, provide a no-fail swap (and provide it correctly). 100
Namespaces and Modules 103
57. Keep a type and its nonmember function interface in the same namespace. 104
58. Keep types and functions in separate namespaces unless they're specifically intended to work together. 106
59. Don't write namespace usings in a header file or before an #include. 108
60. Avoid allocating and deallocating memory in different modules. 111
61. Don't define entities with linkage in a header file. 112
62. Don't allow exceptions to propagate across module boundaries. 114
63. Use sufficiently portable types in a module's interface. 116
Templates and Genericity 119
64. Blend static and dynamic polymorphism judiciously. 120
65. Customize intentionally and explicitly. 122
66. Don't specialize function templates. 126
67. Don't write unintentionally nongeneric code. 128
Error Handling and Exceptions 129
68. Assert liberally to document internal assumptions and invariants. 130
69. Establish a rational error handling policy, and follow it strictly. 132
70. Distinguish between errors and non-errors. 134
71. Design and write error-safe code. 137
72. Prefer to use exceptions to report errors. 140
73. Throw by value, catch by reference. 144
74. Report, handle, and translate errors appropriately. 145
75. Avoid exception specifications. 146
STL: containers 149
76. Use vector by default. Otherwise, choose an appropriate container. 150
77. Use vector and string instead of arrays. 152
78. Use vector (and string::c_str) to exchange data with non-C++ APIs. 153
79. Store only values and smart pointers in containers. 154
80. Prefer pushback to other ways of expanding a sequence. 155
81. Prefer range operations to single-element operations. 156
82. Use the accepted idioms to really shrink capacity and really erase elements. 157
STL: Algorithms 159
83. Use a checked STL implementation. 160
84. Prefer algorithm calls to handwritten loops. 162
85. Use the right STL search algorithm. 165
86. Use the right STL sort algorithm. 166
87. Make predicates pure functions. 68
88. Prefer function objects over functions as algorithm and comparer arguments. 170
89. Write function objects correctly. 172
Type Safety 173
90. Avoid type switching; prefer polymorphism. 174
91. Rely on types, not on representations. 176
92. Avoid using reinterpret_cast. 177
93. Avoid using static_cast on pointers. 178
94. Avoid casting away const. 179
95. Don't use C-style casts. 180
96. Don't memcpy or memcmp non-PODs. 182
97. Don't use unions to reinterpret representation. 183
98. Don't use varargs (ellipsis). 184
99. Don't use invalid objects. Don't use unsafe functions. 185
100. Don't treat arrays polymorphically. 186
Bibliography 187
Summary of Summaries 195
Index 209
作者简介
在本书中，两位知名的C++专家将全球C++团体的集体智慧和经验凝结成一套编程规范。这些规范可以作为每一个开发团队制定实际开发规范的基础，更是每一位C++程序员应该遵循的行事准则。书中对每一条规范都给出了精确的描述，并辅以实例说明；从类型定义到差错处理，都给出了最佳的C++实践。即使使用C++多年的程序员也会从中受益匪浅。
本书适合于各层次C++程序员，也可作为高等院校C++课程的教学参考书。
发布书评
精彩书评 (总计1条)
-
光买了书，唉没时间看书啊！我电脑Z差啊，学得头都大了啊！还好，室友告诉我上猎豹网校，看那个视频课程学。嘿嘿，这是个简单容易的办法！这下不再担心买了书，束之高阁了！
精彩短评 (总计14条)
-
光买了书，唉没时间看书啊！我电脑Z差啊，学得头都大了啊！还好，室友告诉我上猎豹网校，看那个视频课程学。嘿嘿，这是个简单容易的办法！这下不再担心买了书，束之高阁了！
-
受教了； -
其实这本书很鸡肋。因为此书是对一条条的规范、原则、实践等的高度提炼，能力到了自然能理解，能力没到看完也不一定能理解，此时你需要类似《Unix编程艺术》的书，当然你仍然需要足够的实践来支持，要不就会像我一样在这里说大话！
如果你是完美主义者，如果你本来就注重思维训练，那么相信你平时就已经在身体力行这书里的大部分规范了。但是即使如此，此书还至少有两个价值：1.措辞优美，并且大量引经据典，可以找到不少其他优秀的书来进一步的阅读；2.让完美主义者避免掉进“过分完美”的陷阱。
对了，这类思维、习惯方面的话题，并不要求你一定具有C++的知识，其内容一样适用于其他语言，其他语言的知识也一样能助你理解。 -
本评论转自我的Blog
转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址：
http://program-think.blogspot.com/2009/01/cxx-coding-standards-101-rules.html
全书的101个条款分布在如下的12部分中，下面来挨个介绍一下。
1、组织与策略
这部分其实不是讲C++，而是更偏向于软件工程方面。如果你是一个部门或者团队的主管，要仔细思考一下：这些条款你的团队/部门是否都做到了？如果你是一个C++新手，可以先略过这部分。
2、设计风格
这部分讲的是通用程序设计哲学，并不限于C++，而是适用于所有的编程语言。如果你对C++已经入门，但是想再上一个境界，本部分你必须好好领会。我估计有十年编程经验的老手也未必能够完全吃透该部分的所有条款。
3、编码风格
终于开始说到C++语法了！本部分说得都是一些基本的东东，C++新手要好好看看这部分，老手倒未必了。
4、函数与操作符（运算符）
如果你是从其它语言Java和C转到C++，可能对操作符重载还不适应，需要了解一下这部分。如果你原来是Python程序员，估计对操作符重载，应该会比较有亲切感。
5、类设计和继承
最好你已经有了一定的OO理论功底，然后再来看这部分，效果会更好。
6、构造、析构、拷贝
这部分读起来的难度不大。不过有几个几个细节需要注意（即使你已是熟手）。
7、名空间和模块
如果你需要从事规模比较大的C++项目的开发，那么本部分一定要了解一下。比较大的项目一般都会涉及到逻辑分割（分名空间）和物力分割（分模块）。
8、模板与范型
这部分适合已经比较熟悉C++的开发人员，新手可以先略过。
9、错误处理与异常
错误和异常的处理，是编程领域公认的难点。头几条是关于原理性的条款（因此也适用于其它语言），需要深刻领会；后几条是关于C++语法，你如果对try-catch不熟悉的话要注意看看了（即使是2-3年开发经验的，也有许多不熟悉异常处理）。
10、STL容器 11、STL算法
如果你是从其它语言（Java、C）转到C++，或者你原先只用MFC，那么估计你的STL会有欠缺，好好看看这两部分吧。
12、类型安全
如果你是从C转到C++，这部分尤其要注意看一下。里面提到的几个条款都是和C的缺点有关（这么说，C fans看了可别动怒啊）。 -
这本书相当适合有一定C++编程经验的初级，中级程序员阅读。这本书讨论了101个规则，每个规则都按照，固定的格式（包括条款标题，摘要，讨论，示例等部分）进行说明。这样的编排方式即清晰又符合我们理解接受的渐进过程。
也许可以边看书边试着做一些回忆，想想自己是否在编程时候使用或注意到这些规范。还可以问自己一些问题，例如在我们的设计风格中是否注意了，”对一个函数之赋予一种职责“，”正确，简单和清晰第一，软件简单为美（Keep It Simple Software, KISS）“，”优先使用线性算法或者尽可能快的算法：例如O(N)“，”尽量减少全局和共享数据（会增加耦合度，从而降低可维护性，通常还会降低性能）“等等。
我们也可以考虑一下我们的编程风格，并问自己: 我们有没有做到避免使用宏， 尽可能局部声明变量, 总是初始化变量，避免函数过长，避免嵌套过深，是否做到确保所编写的每个头文件都能够独自进行编译。
C++之父Bjarne Stroustrup说过“软件开发最重要的一个方面就是弄清楚自己要构建的是什么”，对于类的设计与继承这一部分也相当值得一读，例如以下条款“用小类代替巨类”，“ 用组合代替继承”，“避免从并非要设计成基类的类中继承”，“优先提供抽象接口”，“共用继承即可替换性。继承，不是为了重用，而是为了被重用，Liskov替换原则: Liskov Substitution Principle，共用继承所建模的必须总是“是一个is a”，更精确的“其行为象一个 works like a ”关系：所有基类约定必须满足这一点。”等等，也许我们对这些规则都了然于胸，但是我们是否时时刻刻注意到这些规则呢，这本书就提供了这样一个“小声音”，提醒我们，在经过一段时间的编程后，我们也许常常会被一些“坏习惯”占据，这个“小声音”，也许就是摒除这些“坏习惯”的利器，
也许你和我一样在编写C++的时候会不自觉地使用了一些不先进的C的方式，例如使用数组，匈牙利标法，switch等等，看了这本书后绝对会大有启发，例如以下的部分书摘：
”匈牙利记法：将类型信息并入变量名的记法，是混用了类型不安全语言（特别是C）中的设施，这在面向对象语言中是可以存在的，但是有害无益，在泛型编程则更不不行。所以，任何C++编程规范都不应该要求使用匈牙利记法，而在规范中选择禁用该记法则是合理的。“
”通过类型分支（type switching）来定制行为既不牢固，容易出错，又不安全，而且是企图用C++编写C代码的明显标志。这是一种很不灵活的技术，要添加新特性时必须回过头对现有代码进行修改。它还不安全，因为添加新类型时，如果忘记修改所有分支，编译器也不会告知。“
“不要使用C语言风格的数组，指针运算和内存管理原语操作实现数组抽象。使用vector或者string不仅更轻松，而且还有助于编写更安全，伸缩性更好的软件。毋庸置疑，在当今软件中缓冲区溢出和安全缺陷是罪魁祸首。固定长度的数组所带来的愚蠢限制，即使仍在正确界限内，也是软件开发人员的一大困扰。”
”不要使用C风格的强制转换。“
初级，中级程序员看了本书后一定会大有收获，掌握这些规范，也许是成长为优秀程序员的重要的坚实一步。
------- ------
本文原始地址：http://hanyionet.blogspot.com/2009/09/blog-post_20.html -
引用pongba的话：C++中众多的细节虽然在库设计者手里面有其用武之地，但普通程序员则根本无需过多关注，尤其是没有实际动机的。
关注编码实践准则才是真正需要花时间掌握的东西! -
名字起的很有吸引力，其实内容很多章节讲的东西，都是<<effective c++>>里面的，我不知道原版书的文采怎么样？所以我不好妄加评论，但这本中文版的译者的翻译水平，我真的不敢苟同，翻译的僵硬，晦涩，缺乏灵活性，估计就是逐字翻译的，唉，浪费了我几十块钱，买了一本多余的书！ -
号称是20年集大成之作，罗列了一大堆最佳实践的条款
有口号，有说明，有实作，形式上挺好
前面一些谈设计，组织，策略上的条款是很实在，后面展开谈细节，模板，异常，容器，算法之类，就难逃教条主义的嫌疑了，晦涩，模糊，说服力不强
中间用的例子有些也不是很清晰贴切 -
日特特与 -
比较轻量级的一本书。如果你已经看过 effective c++ ，exceptional c++系列，那这本书只用翻翻目录就行了。 -
现代c++程序员必读。 -
温故而知新，重新复习一些C++的知识，有一段时间，出现了非常多关于C++编程规范类型的书籍。这些类型的书籍，很大部分内容是相同的，个人比较喜欢看《C++编程规范》，100条，条款来自《Effective C++》、《More Effective C++》、《Effective STL》、《Exceptional C++》、《More Exceptional C++》等各类书籍。
多年以后重新开始看这本书，又有新的收获：
1、不要拘泥小节
前段时间进行项目开发，小组内的开发人员可以说都是很优秀的开发人员，大家在一起开发，我想总希望能有一个基本的编程规范，很犹豫对于编程规范定义到什么级别。对于缩进、行的长度、注释、大括号的形式大家都有自己习惯的形式，对于这些编写的规范，说实话真的没有太大的必要。不管哪一种形式，只要代码比较清晰，很快就能习惯，读取代码（Review）都比较容易。对于函数名和变量名则需要统一的命名方式，这是大家都比较容易达成共识的编程规范，不要花太多时间去规范一些没有必要的规则，否则阻力很大，效果很差。
2、在高警告级别进行编译
最近一些开发工作主要是类库的开发，API的设计，所以对于代码的质量要求很高，这就要求对于编译器的各种警告都非常注意，很多bug的引入就是warning开始，很常见的unsigned int和int的转换比较，unsinged int的--操作、浮点数的精度问题等。
3、代码审查上的投入
项目的开发很产品的开发，其中一个很大的区别就在于生命周期的长短，项目只要验收了就可以，不一定会有后续的项目，但是产品的开发，生命周期很长（当然，因为产品被淘汰另当别论），代码的质量就非常的重要，根据用户的反馈，产品模块的优化升级。如果代码质量差，优化升级会成为一个很痛苦的过程，在产品的开发过程中，要在代码审查中投入。
4、正确、简单和清晰第一
上周和同事进行XP编程，发现同事很喜欢直接用调用函数并将函数的返回值作为参数传递，个人喜欢上非常不喜欢这种优化，一是调试很多时候无法看到返回值（纯虚类的接口）。二代码的清晰被破坏，可读性变差。再则我觉得这种优化根本没有必要，都是基本类型的。
5、积极使用Const
在做API设计的时候，需要考虑API的各种使用情况，需要提供const和非const的版本。
6、考虑将虚拟函数申明为非公用的，将公用函数申明为非虚拟的
在API设计中，经常会采用多层设计，实现类的设计中引入了虚拟函数和公用函数，避免公用函数被重载。
7、广泛的使用断言记录内部假设和不变式
越底层，越要采用断言，避免不要的条件判断影响性能以及错误的引入。
8、正确的报告、处理和转换错误
API的设计，一定要有这些处理和Log，否则用户无法知道错误的原因，导致可用性非常的差。
9、显式定义构造函数、析构函数、拷贝构造函数和复制函数。
10、还有一点是关于继承实现中的前置条件和后置条件的定义要非常的清晰明确。
《C++编程规范》的很多条例也是根据OOD的五大原则进行设计的。
1、单一职责原则（SRP）
2、开放-封闭原则
3、Liskov替换原则
4、依赖倒置原则
5、接口隔离原则
-
技巧比较实用 -
其实我想看个实践，别人的方法。
副标题叫Best Practices，但是Practice很少。
这本书的内容都缺少实践，站着说话不腰疼，对于我这样的菜鸟感觉是这样的。
比如这条，比如有个巨类：
CHugeClass
{
function0();
function1();
function2();
function3();
....
function98();
function99();
}
使用组合代替继承（第34条）
把上面的类变成：
CBigClass
{
smallClass0;
smallClass1;
smallClass2;
smallClass3;
......
smallClass10;
}
使用的时候从huge.func()变成huge.small.func()，但是好像牺牲一下使用上的灵活。
谁愿意就这个问题讨论一下。