摘要
只规定需要规定的事情：不要强制施加个人喜好或者过时的做法。
讨论
有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。
应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格（style）之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。
下面列举了几种常见的情况，在这里重要的不是设定规则，而是与所维护的文件中已经使用的体例保持一致。
● 不要规定缩进多少，应该规定要用缩进来体现代码的结构。缩进空格的数量可以遵照个人习惯，但是至少在每个文件中应该保持一致。
● 不要强制行的具体长度，应该保证代码行的长度有利于阅读。可以遵照个人习惯来决定行长，但是不要过长。研究表明，文字长度不超过10个单词最利于阅读。
● 不要在命名方面规定过多，应该规定的是使用一致的命名规范。只有两点是必需的：（1）永远不要使用“晦涩的名称”，即以下划线开始或者包含双下划线的名称；（2）总是使用形如ONLY_UPPERCASE_NAMES的全大写字母表示宏，不要考虑使用常见的词或者缩略语作为宏的名称（包括常见的模板参数，比如T和U；像#define T anything这样的代码是极容易混淆的）。此外，应该使用一致的、有意义的名称，遵循文件的或者模块的规范。（如果你无法决定自己的命名规范，可以尝试如下命名规则：类、函数和枚举的名称形如LikeThis，即单词首字母大写；变量名形如likeThis，即第一个单词首字母小写，第二个单词首字母大写；私有成员变量名形如likeThis_；宏名称形如LIKE_THIS。）
● 不要规定注释风格（除非需要使用工具从特定的体例中提取出文档），应该编写有用的注释。尽可能编写代码而不是写注释（比如，见第16条）。不要在注释中重复写代码语义，这样很容易产生不一致。应该编写的是解释方法和原理的说明性注释。
最后，不要尝试强制实施过时的规则（见例3和例4），即使它们曾经在一些比较陈旧的编程规范中出现过。
示例
例1 大括号的位置。以下代码在可读性方面并不存在区别：
① 这是纯C（K&R）风格的括号位置，如函数名所示。——译者注
② 每个括号一行，如函数名所示。——译者注
③ 每个括号一行并缩进，如函数名所示。——译者注
任何一个专业程序员都能够毫无困难地阅读和编写这些体例中的任何一种。但是应该保持一致：不要随意地或者以容易混淆作用域嵌套关系的方式放置大括号，要尽量遵循每个文件中已经使用的体例。在本书中，对大括号位置的选择主要是为了能够在编辑允许范围内得到最佳可读性。
例2 空格与制表符。有些团队禁用制表符（比如[BoostLRG]），因为不同的编辑器中制表符的设定是不同的，如果使用不当，会将缩进变为“缩出”和“无缩进”。其他同样受人尊敬的团队则允许使用制表符，并采取了一些能够避免其潜在缺陷的规定。这都是合理的，其实只要保持一致即可：如果允许使用制表符，那么要确保团队成员维护彼此的代码时，不会影响代码的清晰和可读性（见第6条）。如果不允许使用制表符，应该允许编辑器在读入源文件时将空格转换为制表符，使用户能够在编辑器中使用制表符，但是在将文件写回时，一定要将制表符转换回空格。
例3 匈牙利记法。将类型信息并入变量名的记法，是混用了类型不安全语言（特别是C）中的设施，这在面向对象语言中是可以存在的，但是有害无益，在泛型编程中则根本不可行。所以，任何C++编程规范都不应该要求使用匈牙利记法，而在规范中选择禁用该法则是合理的。
例4 单入口，单出口（SESE, Single Entry, Single Exit）。历史上，有些编程规范曾经要求每个函数都只能有一个出口，也就意味着只能有一个return语句。这种要求对于支持异常和析构函数的语言而言已经过时了，在这样的语言中，函数通常都有多个隐含的出口。取而代之，应该遵循类似于第5条那样的标准，即直接提倡更简单的、更短小的函数，这样的函数本身更易于理解，更容易防错。