C++ Coding Standards:序言

By Herb Sutter, Andrei Alexandrescu 著

树人译

序言

及早地墨守成规：用相同的方法处理相同的过程。积累惯用法。标准化。你和莎士比亚之间的唯一差别就是习语表的长度，而不是词汇量。

Alan Perlis

标准最大好处就是带来那么多的选择。

Variously attributed

    我们提供这本书作为你们团队的编码标准的基础有以下两个主要原因：

l          一个标准应该反映一个团体的最好的经得起考验的经验：它应该包括基于实际经验的已经被认可的习惯用法和可靠的易于理解的语言。特别是一个编码标准，它应该以广泛和丰富的软件开发文学为坚实的基础，把那些可能流散到各处的准则、指导方针和最佳实践组合到一起来。

l          自然界里是没有真空的：如果你不能自觉地展示合理的准则，通常其他人也不会展示他们自己所拥有的珍贵的准则。一个编码标准通常都有其全部的最小欲望特性集（desirable properties）；例如，很多标准都试图促成一个C++的最低限度的C-style用法。

一些不甚了解语言，也不甚了解软件开发，但又试图制定规则的人制定了一些不良的编码标准。一个不良的编码标准很快就会失去信任，就算是它的一些有效的指导方针也可能被那些不再着迷的程序员所忽略，这些程序员不喜欢也不赞同它那些更差的指导原则。最坏情况就是这个不良的编码标准在实践中被强制使用。

怎样使用这本书

思考。用心去遵循好的指导方针；而不要盲目地遵从。在这本书的条款中，留意那些例外情况，它们在非一般的情况下可能不适用。没有指导方针集合，但有好的（而且我们也认为他们是）就应该尽量去思考。

每个开发团队都有责任去制定它自己的标准，而且要认真负责地去制定。也包括你的团队。如果你是一个团队的头头，那就让团队成员参与制定团队的标准；人们往往更容易接受那些自己拥有的标准，而不是一大堆他们感觉像是强加的准则。

这本书是用来作为你的团队的编码标准的基础，也可以作为被引用的文献。它并不是编码标准的最新成果，因为你的团队会有另外一些适合于特定小组或任务的指导方针，而且你也可以自由地把它们添加进来。但我们希望这本书能通过文档化和引用一些被普遍应用（注意例外情况）和广泛接受的权威性实践，来节省你作同类工作的时间，以此帮助你提高质量和你所使用的编码标准的一致性。

让你的团队根据自己的基础阅读这些指导方针（例如：整本书，选定条款所应用的其它文献），确定是否存在任何你的团队不能完全接受的指导方针（例如：因为你的项目的特有特征）。接下来确认剩下的事情。一旦采纳了，就不能违反团队的编码标准，除非经过了整个团队的协商。

最后，定期审查团队的指导方针，使其包含实践经验，并且从现实使用中得到反馈。

编码标准和你

编码标准可以提供很多相关的好处：

l          改善的代码质量：鼓励开发者用一致的方法做正确的事来提高软件质量和可维护性。

l          改善的开发速度：开发者没必要总是从第一个原理来作决断。

l          更好的团队协作：减少不必要的对无意义的问题的争论而且使得成员更容易阅读和维护彼此的代码。

l          适当维度的一致性：解放开发者，使他们在相关方向上具有创造性。

Uniformity in the right dimension: This frees developers to be creative in directions that matter.

在心理和时间压力下，人们做着他们被训练去做的事情。他们会求助于习惯。这就是为什么医院的ER Units要雇佣有经验的，训练有素的人员；尽管会使那些博学的新手感到莫名其妙。

过去作为软件开发人员，我们经常性地面临要交付明天的软件的巨大压力。在进度压力下，我们做我们被训练去做的事情而且习惯于那样做。在正常时间不知道软件工程最佳实践（或者不习惯于用它们）的Sloppy程序设计人员，当压力来临时,他们会写出更加sloppy和buggy的代码来。相反地，那些遵循好的习惯并且有规律地实践它们的程序设计人员有自组织能力，而且可以更快地交付高质量代码。

本书介绍的编码标准是编写高质量C++代码的指导方针的一个集合。它们是从C++社区的丰富的集体的经验中提取出来的结论。很多知识只是零碎地分布在很多书中，或者是口述的至理名言。本书的意图就是收集这些知识，使它们成为简洁、合理的，易于理解和遵循的准则的一个集合。

当然，我们也可能用最佳编码标准写出不良的代码来。这对其他任何语言，过程或方法论也是一样的。一个优秀的编码标准鼓励那些超越原始准则的好的习惯和规程。一旦被接受，这个基础就向更高的层次敞开大门。这里没有快捷方式；写诗之前你必须积累词汇和语法，我们只是希望可以使这个过程更容易些。

我们向所有层次的C++设计人员推荐这本书：

如果你是一个初学者，我们希望你可以得到一些准则和它们的基本原理，基本原理可以帮助你理解什么风格和惯用法是C++天生就支持的。每个准则和指导方针我们都提供了一个简明的基本原理和讨论，促使你能够理解，而不仅仅是死记硬背这些准则和指导方针。

对于中级或高级程序设计人员，我们已经尽量为每个准则提供一份有精确参考的详细列表。这样，你就可以在C++的类型系统，语法和对象模型中更深入地探究各个准则的根源了。

不论如何，你很可能是在一个开发复杂项目的团队中工作。这就是编码标准可以回报你的地方了，你可以用它们来把团队带到一个共同的水平上来，而且提供了一个代码走查的基础。

关于这本书

这本书中我们从以下两个设计目标出发：

l          短小比冗长更好：庞大的编码标准趋向于被忽视；短小易于阅读和使用。冗长的条款更容易被忽视，短小的条款易于阅读和使用。

l          各个条款不得有争议：本书文档化被广泛认同的标准，而不是创造他们。如果一条指导方针并非在所有情况下适用，它就会以这种发式出现（例如：“consider X…”替代“do X…”），而且我们要留意被广泛接受的例外情况。

l          各个条款必须具有权威性：本书中的指导方针是以其它一些已出版的著作作为基础的。本书也提供了一个相关C++文献的索引。

l          各个条款必须有谚语来概括：我们没有选择去定义一些新的指导方针，而是选择了那些已经被编译器强制和探测到的，或者是已经在其他条款中讨论过的事实。

例：“不要返回一个指向自动变量的指针/引用”就是一个好的指导方针，但在本书中我们并没有包括它，因为我们试过的所有编译器都已经为此发出一个警告，而且这个问题已经在Item1中讨论过“以最高的警告级别编译”。

例：“使用编译器（或者编译器，或者调试器）”也是一个好的指导方针，但是，在没有被告之的情况你都理所当然会想法设法用那些工具；一个替换策略，我们花了前四条中的两条来讨论“使用自动化构建系统”和“使用版本控制系统”。

例：“不能滥用goto”是一个伟大的条款，但在我们这些有经验的设计人员中无人不晓，它也就没有再说的必要了。

每个条款都用如下的布局：

l          条款标题：我们可以提出来作为一个规则的助记符号的最简单的有意义的原声摘要。

l          摘要：简要地陈述最基础的点。

l          讨论：指导方针的一个扩展说明。通常包括简短的基本原理，但是要记住基本原理的大多数都有意地留在了参考中。

l          示例（如果适用的话）：用以示范规则的例子或者帮助记忆。

l          例外（如果适用的话）：任何（通常都很少）这条规则不能应用的情况。但要小心太快认为“Oh，我很特殊；它不能应用到我的身上”的陷阱，它合理性很普遍，但通常都是错误的。

l          参考：要了解完整的细节和分析可以阅读这些C++文献。

在每个章节我们会推荐一个“最有价值条款（MVI）”。通常它都是每一节的第一个条款，因为在每个部分我们都尽量把重要的条款放到前面；但有些时候重要条款不能放在前面，主要是出于流程和可阅读性的原因，而且我们也觉得有必要以这种方式呈现它，用以提示需特别注意。