C++编程规范101条规则与最佳实践0.pdfVIP

组织和策略问题 如果人们按照程序员编程的方式修建房屋， 那么一只啄木鸟就能毁灭整个文明。 ——Gerald Weinberg① 为了遵从C 和C++ 的伟大传统，我们从0 开始编号。首要的指导原则，也就是第0 条，阐 明了我们认为对编程规范而言最为基本的建议。 接下来，这个导论性部分的其他条款将主要讲述几个精心选择的基本问题，这些问题大多数 与代码本身并没有直接关系，它们讨论的是编写坚实代码所必需的工具和技术。 本部分中我们选出的最有价值条款是第 0 条：“不要拘泥于小节”（又名：“了解哪些东西不 应该标准化”）。 ① Gerald Weinberg 是著名的软件思想家（他自称thinker ），因《程序开发心理学》等书名世，以对软件 开发的深刻洞察而著称。——译者注 2 C++编程规范：101 条规则、准则与最佳实践 0 第 条 ① 不要拘泥于小节 （又名：了解哪些东西不应该标准化） 摘要 只规定需要规定的事情：不要强制施加个人喜好或者过时的做法。 讨论 有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编 程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。 应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格 （style ）之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。 下面列举了几种常见的情况，在这里重要的不是设定规则，而是与所维护的文件中已经使用 的体例保持一致。  不要规定缩进多少，应该规定要用缩进来体现代码的结构。缩进空格的数量可以遵照个 人习惯，但是至少在每个文件中应该保持一致。  不要强制行的具体长度，应该保证代码行的长度有利于阅读。可以遵照个人习惯来决定 行长，但是不要过长。研究表明，文字长度不超过 10 个单词最利于阅读。  不要在命名方面规定过多，应该规定的是使用一致的命名规范。只有两点是必需的：（1） 永远不要使用“晦涩的名称”，即以下划线开始或者包含双下划线的名称；（2 ）总是使用 形如 ONLY_UPPERCASE_NAMES 的全大写字母表示宏，不要考虑使用常见的词或者缩略 语作为宏的名称（包括常见的模板参数，比如T 和U；像#define T anything 这样的代码 是极容易混淆的）。此外，应该使用一致的、有意义的名称，遵循文件的或者模块的规范。 （如果你无法决定自己的命名规范，可以尝试如下命名规则：类、函数和枚举的名称形如 LikeThis，即单词首字母大写；变量名形如 likeThis，即第一个单词首字母小写，第二个 单词首字母大写；私有成员变量名形如likeThis_；宏名称形如LIKE_THIS。）  不要规定注释风格（除非需要使用工具从特定的体例中提取出文档），应该编写有用的 注释。尽可能编写代码而不是写注释（比如，见第 16 条）。不要在注释中重复写代码语 义，这样很容易产生不一致。应该编写的是解释方法和原理的说明性注释。 最后，不要尝试强制实施过时的规则（见例 3 和例 4 ），即使它们曾经在一些比较陈旧的编 程规范中出现过。 示例 ① 出自Richard Carlson 的畅销书Don ’t Sweat the Small Stuff …and It s all Small Stuff’ ，中文版译名为《别为小事 抓狂》。——译者注 组织和策略问题 3 例1 大括号的位置。以下代码在可读性方面并不存在区别： void using_k_and_r_style() { // „„ }① void putting_each_brace_on_its_own_line() { // „„