C++ 编程规范
这是一本 由两位世界顶级专家联袂巨献，适合所有层次 C++程序员 的 C++ 界20年集大成之作，这里有 101 条关于 C++ 编程的规则、总则与最佳实践。
目录
编程规范与人的关系
好的编程规范能够带来下列许多相互关联的优点：
改善代码质量
鼓励开发人员一贯地正确行事，从而能够直接提高软件的质量和可维护性。
提高开发速度
开发人员不需要总是从一些基本原则出发进行决策。
增进团队精神
有助于减少在一些小事上不必要的争论，使团队成员更容易阅读和维护其他成员的代码。
在正确的方向删取得一致
使开发人员放开手脚，在有意义的方向上发挥创造性。
第0条：不要拘泥于小节
（又名：了解哪些东西不应该标准化）
只规定需要规定的事情
- 不要强制施加个人喜好或者过时的做法:
有些问题只是个人喜好，并不影响程序的正确性或可读性，所以这些问题不应该出现在编程规范中，任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。
在每个源文件和项目中使用一致的格式
- 同一段代码中要在几种编程风格(style)之间换来换去是很不舒服的。
- 但是无需再多个项目或者整个公司范围内强制实施一致的格式。
这里我们列举几种常见的情况，重要的不是设定规则，而是与所维护的文件中已使用的体例保持一致：
不要规定缩进多少
- 应该规定要用缩进来体现代码的结构；
- 缩进空格的数量可以遵照个人习惯；
- 但是至少在每个文件中保持一致。
不要强制行的具体长度
- 应该保证代码行的长度有利于阅读；
- 可以遵照个人习惯来决定行长，但是不要过长；
- 研究表明，文章长度不超过10个单词最利于阅读。
不要在命名方面规定过多
应该规定的是使用一致的命名规范：只有两点是必需的：
- 1.不要使用晦涩的名称
即以下划线开始或者包含双下划线的名称 - 2.总是使用形如 ONLY_UPPERCASE_NAMES 的 全大写字母表示宏 ，
- 不要考虑使用常见的词或者缩略语作为宏的名称（包括常见的模板参数，比如T和U，#define T anything 这样的代码是极容易混淆的）；
- 另外，应该使用一致的、有意义的名称，遵循文件的或者模块的规范，如果你无法决定自己的命名规范，可以尝试如下的命名规范：
- 类、函数和枚举的名称形如LikeThis,即单词首字母大写；
- 变量形如likeThis_;
- 宏名形如LIKE_THIS。
不要规定注释体例
- 除非需要使用工具从特定的体例中提取出文档；
- 应该编写有用的注释；
- 尽可能编写代码而不是注释；
- 不要在注释中重复学代码语义，这样很容易产生不一致；
- 应该编写的是解释方法和原理的说明性注释。
不要尝试实施陈旧的规则
- 即使他们曾经子一些比较陈旧的编程规范中出现过。