C++ Coding Standards:Item0不要为小事斤斤计较

By Herb Sutter, Andrei Alexandrescu 著

树人 译

Item0 不要为小事斤斤计较（或者说是：知道什么东西不需要标准化）

摘要：

少说废话，捡有必要的说：不要把个人的品味或废弃的实践强加于他人。

讨论：

仅仅是个人的品味和不会影响正确性或可读性的问题不能加到编码标准中来。任何专业程序设计人员都可以很轻松地阅读和编写同他们所习惯的格式稍有不同的代码。

应该在各个源文件甚至各个项目中使用一致的格式，因为在同一块代码中于几种风格之间切换显得有些不合谐。但是别试图跨多个项目或在一个公司中强制一致的格式编排。

如下的几个共通的条款，没有设定某个尺度，仅仅是为了与你正在维护的文件中已经在使用的风格保持一致：

l          不要规定缩进的大小，但要能展示结构：只要你喜欢，你可以缩进任意大小的空格，但至少要在各个文件中保持一致。

l          不要规定一行的长度，但要保持可读性：只要你喜欢，你可以使用任意长度的行，但不要太过份了。研究表明等于10个单词的文本对眼睛观察是最优的。

l          不要过度地制定命名规则，但要使用一致的命名约定：只有两个必需的：a）决不要使用“秘密的名字”，像那些以一个下划线或两个下划线打头的名字；b）对于宏总是使用ONLY_UPPERCASE_NAMES（仅有大写字母组成），决不要认为编写一个宏它就是一个公共单词或缩写词（包括公共模板参数，像T和U这样的；写下#define T anyting 这样的东西是极其分裂的）。另外，要使用一致的有意义的名字，而且要遵循一个文件或模块的约定。（如果你不能决定你自己的命名约定，就试试这个吧：Name classes, functions, and enums LikeThis; name variables likeThis; name private member variables likeThis_; and name macros LIKE_THIS.）。

l          不要规定注释风格（除非有工具可以把特定风格转换为文档），但要编写有用的注释：只要可能就用代码替换注释（参见：Item16）。不要写重复代码的注释；它们可以同步获得。要写解释方法和原理的说明性的注释。

最后，不要强制使用过时的规则（参见例3和例4），尽管它们在过时的编码标准中曾经出现过。

示例：

例1：大括号布局。下面的代码没有可读性的差异：

void using_k_and_r_style() {

// …

}

void putting_each_brace_on_its_own_line()

{

// …

}

void or_putting_each_brace_on_its_own_line_idented()

  {

  // …

  }

任何专业程序设计人员都可以毫不费力地阅读和编写以上的风格。但要保持一致性：不要随意地放置大括号或者使用模糊作用域嵌套的方式，而且要尽量采用在各个文件中已经在使用中的风格。本书中，我们放置大括号的方式是在我们编辑的约束范围内最大化可阅读性。

例2：空格vs制表符。由于各个编辑器对制表符的处理不一样，而且当使用不当时，会把缩进弄成outdenting和nondenting，一些团队选择禁止使用制表符（例如[BoostLRG]）。其他一些同样可敬的团队则允许使用制表符，而且采用一些规则来避免制表符的潜在的缺点。只要一致就好：如果允许制表符，应该确保团队成员在维护彼此的代码时不会造成代码清晰度和可读性方面的代价（参见Item6）。如果禁止制表符，应该允许编辑器在读取一个源文件时可以把空格转换为制表符，以便用户在使用编辑器时可以使用制表符，但要确保在写回文件时可以把制表符转换为空格。

例3：匈牙利标记法。已经混合进了一些类型不安全的语言中（尤其是C）中在变量名中结合类型信息的标记法，在面向对象语言中是可能的，但这样做毫无益处（只有坏处），但不可能出现在泛型程序设计中。因此，尽管一个C++编码标准可能明令禁止匈牙利标记法，但没有哪个C++编码标准真正需要它。

例4：单进单出（”SESE”）。从历史的观点来看，一些编码标准规定每个函数只能有一个出口，也就是一个return语句。这样的规定在支持异常和析构函数的语言中被舍弃了，函数可以有多个隐示的出口。作为替换规则，我们可以遵循像Item5一样的准则：提倡使用更简单更短小的函数，易于理解和实现容错是这些函数固有的特征。