diff --git a/google-cpp-styleguide/classes.rst b/google-cpp-styleguide/classes.rst index d7893ed..7586685 100644 --- a/google-cpp-styleguide/classes.rst +++ b/google-cpp-styleguide/classes.rst @@ -1,5 +1,6 @@ 3. 类 ------------ +TODO 类是 C++ 中代码的基本单元. 显然, 它们被广泛使用. 本节列举了在写一个类时的主要注意事项. @@ -8,7 +9,7 @@ .. tip:: 构造函数中只进行那些没什么意义的 (trivial, YuleFox 注: 简单初始化对于程序执行没有实际的逻辑意义, 因为成员变量 "有意义" 的值大多不在构造函数中确定) 初始化, 可能的话, 使用 ``Init()`` 方法集中初始化有意义的 (non-trivial) 数据. - + 定义: 在构造函数体中进行初始化操作. @@ -17,7 +18,7 @@ 缺点: 在构造函数中执行操作引起的问题有: - + - 构造函数中很难上报错误, `不能使用异常 <#...>`_. - 操作失败会造成对象初始化失败，进入不确定状态. - 如果在构造函数内调用了自身的虚函数, 这类调用是不会重定向到子类的虚函数实现. 即使当前没有子类化实现, 将来仍是隐患. @@ -37,15 +38,15 @@ 优点: 默认将结构体初始化为 "无效" 值, 使调试更方便. - + 缺点: 对代码编写者来说, 这是多余的工作. 结论: 如果类中定义了成员变量, 而且没有提供其它构造函数, 你必须定义一个 (不带参数的) 默认构造函数. 把对象的内部状态初始化成一致/有效的值无疑是更合理的方式. - + 这么做的原因是: 如果你没有提供其它构造函数, 又没有定义默认构造函数, 编译器将为你自动生成一个. 编译器生成的构造函数并不会对对象进行合理的初始化. - + 如果你定义的类继承现有类, 而你又没有增加新的成员变量, 则不需要为新类定义默认构造函数. 3.3. 显式构造函数 @@ -59,13 +60,13 @@ 优点: 避免不合时宜的变换. - + 缺点: 无 结论: 所有单参数构造函数都必须是显式的. 在类定义中, 将关键字 ``explicit`` 加到单参数构造函数前: ``explicit Foo(string name);`` - + 例外: 在极少数情况下, 拷贝构造函数可以不声明成 ``explicit``. 作为其它类的透明包装器的类也是特例之一. 类似的例外情况应在注释中明确说明. .. _copy-constructors: @@ -75,29 +76,29 @@ .. tip:: 仅在代码中需要拷贝一个类对象的时候使用拷贝构造函数; 大部分情况下都不需要, 此时应使用 ``DISALLOW_COPY_AND_ASSIGN``. - + 定义: 拷贝构造函数在复制一个对象到新建对象时被调用 (特别是对象传值时). 优点: 拷贝构造函数使得拷贝对象更加容易. STL 容器要求所有内容可拷贝, 可赋值. - + 缺点: C++ 中的隐式对象拷贝是很多性能问题和 bug 的根源. 拷贝构造函数降低了代码可读性, 相比传引用, 跟踪传值的对象更加困难, 对象修改的地方变得难以捉摸. 结论: 大部分类并不需要可拷贝, 也不需要一个拷贝构造函数或重载赋值运算符. 不幸的是, 如果你不主动声明它们, 编译器会为你自动生成, 而且是 ``public`` 的. - + 可以考虑在类的 ``private:`` 中添加拷贝构造函数和赋值操作的空实现, 只有声明, 没有定义. 由于这些空函数声明为 ``private``, 当其他代码试图使用它们的时候, 编译器将报错. 方便起见, 我们可以使用 ``DISALLOW_COPY_AND_ASSIGN`` 宏: .. code-block:: c++ - + // 禁止使用拷贝构造函数和 operator= 赋值操作的宏 // 应该类的 private: 中使用 - + #define DISALLOW_COPY_AND_ASSIGN(TypeName) \ TypeName(const TypeName&); \ void operator=(const TypeName&) - + 在 ``class foo:`` 中: .. code-block:: c++ @@ -105,11 +106,11 @@ public: Foo(int f); ~Foo(); - + private: DISALLOW_COPY_AND_ASSIGN(Foo); }; - + 如上所述, 绝大多数情况下都应使用 ``DISALLOW_COPY_AND_ASSIGN`` 宏. 如果类确实需要可拷贝, 应在该类的头文件中说明原由, 并合理的定义拷贝构造函数和赋值操作. 注意在 ``operator=`` 中检测自我赋值的情况 (yospaly 注: 即 ``operator=`` 接收的参数是该对象本身). 为了能作为 STL 容器的值, 你可能有使类可拷贝的冲动. 在大多数类似的情况下, 真正该做的是把对象的 *指针* 放到 STL 容器中. 可以考虑使用 ``std::tr1::shared_ptr``. @@ -121,8 +122,8 @@ .. tip:: 仅当只有数据时使用 ``struct``, 其它一概使用 ``class``. - -在 C++ 中 ``struct`` 和 ``class`` 关键字几乎含义一样. 我们为这两个关键字添加我们自己的语义理解, 以便为定义的数据类型选择合适的关键字. + +在 C++ 中 ``struct`` 和 ``class`` 关键字几乎含义一样. 我们为这两个关键字添加我们自己的语义理解, 以便未定义的数据类型选择合适的关键字. ``struct`` 用来定义包含数据的被动式对象, 也可以包含相关的常量, 但除了存取数据成员之外, 没有别的函数功能. 并且存取功能是通过直接访问位域 (field), 而非函数调用. 除了构造函数, 析构函数, ``Initialize()``, ``Reset()``, ``Validate()`` 外, 不能提供其它功能的函数. @@ -151,11 +152,11 @@ 结论: 所有继承必须是 ``public`` 的. 如果你想使用私有继承, 你应该替换成把基类的实例作为成员对象的方式. - + 不要过度使用实现继承. 组合常常更合适一些. 尽量做到只在 "是一个" ("is-a", YuleFox 注: 其他 "has-a" 情况下请使用组合) 的情况下使用继承: 如果 ``Bar`` 的确 "是一种" Foo, ``Bar`` 才能继承 ``Foo``. - + 必要的话, 析构函数声明为 ``virtual``. 如果你的类有虚函数, 则析构函数也应该为虚函数. 注意 `数据成员在任何情况下都必须是私有的 <....>`_. - + 当重载一个虚函数, 在衍生类中把它明确的声明为 ``virtual``. 理论依据: 如果省略 ``virtual`` 关键字, 代码阅读者不得不检查所有父类, 以判断该函数是否是虚函数. .. _multiple-inheritance: @@ -171,13 +172,13 @@ 优点: 相比单继承 (见 :ref:`继承 `), 多重实现继承可以复用更多的代码. - + 缺点: 真正需要用到多重 *实现* 继承的情况少之又少. 多重实现继承看上去是不错的解决方案, 但你通常也可以找到一个更明确, 更清晰的不同解决方案. - + 结论: 只有当所有父类除第一个外都是 :ref:`纯接口类 ` 时, 才允许使用多重继承. 为确保它们是纯接口, 这些类必须以 ``Interface`` 为后缀. - + .. note:: 关于该规则, Windows 下有个 :ref:`特例 `. @@ -189,23 +190,23 @@ .. tip:: 接口是指满足特定条件的类, 这些类以 ``Interface`` 为后缀 (不强制). - + 定义: 当一个类满足以下要求时, 称之为纯接口: - + - 只有纯虚函数 ("``=0``") 和静态函数 (除了下文提到的析构函数). - 没有非静态数据成员. - 没有定义任何构造函数. 如果有, 也不能带有参数, 并且必须为 ``protected``. - 如果它是一个子类, 也只能从满足上述条件并以 ``Interface`` 为后缀的类继承. 接口类不能被直接实例化, 因为它声明了纯虚函数. 为确保接口类的所有实现可被正确销毁, 必须为之声明虚析构函数 (作为上述第 1 条规则的特例, 析构函数不能是纯虚函数). 具体细节可参考 Stroustrup 的 *The C++ Programming Language, 3rd edition* 第 12.4 节. - + 优点: 以 ``Interface`` 为后缀可以提醒其他人不要为该接口类增加函数实现或非静态数据成员. 这一点对于 :ref:`多重继承 ` 尤其重要. 另外, 对于 Java 程序员来说, 接口的概念已是深入人心. - + 缺点: ``Interface`` 后缀增加了类名长度, 为阅读和理解带来不便. 同时，接口特性作为实现细节不应暴露给用户. - + 结论: 只有在满足上述需要时, 类才以 ``Interface`` 结尾, 但反过来, 满足上述需要的类未必一定以 ``Interface`` 结尾. @@ -214,16 +215,16 @@ .. tip:: 除少数特定环境外，不要重载运算符. - + 定义: 一个类可以定义诸如 ``+`` 和 ``/`` 等运算符, 使其可以像内建类型一样直接操作. - + 优点: 使代码看上去更加直观, 类表现的和内建类型 (如 ``int``) 行为一致. 重载运算符使 ``Equals()``, ``Add()`` 等函数名黯然失色. 为了使一些模板函数正确工作, 你可能必须定义操作符. - + 缺点: 虽然操作符重载令代码更加直观, 但也有一些不足: - + - 混淆视听, 让你误以为一些耗时的操作和操作内建类型一样轻巧. - 更难定位重载运算符的调用点, 查找 ``Equals()`` 显然比对应的 ``==`` 调用点要容易的多. - 有的运算符可以对指针进行操作, 容易导致 bug. ``Foo + 4`` 做的是一件事, 而 ``&Foo + 4`` 可能做的是完全不同的另一件事. 对于二者, 编译器都不会报错, 使其很难调试; @@ -232,13 +233,13 @@ 结论: 一般不要重载运算符. 尤其是赋值操作 (``operator=``) 比较诡异, 应避免重载. 如果需要的话, 可以定义类似 ``Equals()``, ``CopyFrom()`` 等函数. - + 然而, 极少数情况下可能需要重载运算符以便与模板或 "标准" C++ 类互操作 (如 ``operator<<(ostream&, const T&)``). 只有被证明是完全合理的才能重载, 但你还是要尽可能避免这样做. 尤其是不要仅仅为了在 STL 容器中用作键值就重载 ``operator==`` 或 ``operator<``; 相反, 你应该在声明容器的时候, 创建相等判断和大小比较的仿函数类型. - + 有些 STL 算法确实需要重载 ``operator==`` 时, 你可以这么做, 记得别忘了在文档中说明原因. - + 参考 :ref:`拷贝构造函数 ` 和 :ref:`函数重载 `. - + 3.10. 存取控制 ~~~~~~~~~~~~~~~~~~~~~ @@ -256,11 +257,11 @@ .. tip:: 在类中使用特定的声明顺序: ``public:`` 在 ``private:`` 之前, 成员函数在数据成员 (变量) 前; - + 类的访问控制区段的声明顺序依次为: ``public:``, ``protected:``, ``private:``. 如果某区段没内容, 可以不声明. 每个区段内的声明通常按以下顺序: - + - ``typedefs`` 和枚举 - 常量 - 构造函数 @@ -279,7 +280,7 @@ .. tip:: 倾向编写简短, 凝练的函数. - + 我们承认长函数有时是合理的, 因此并不硬性限制函数的长度. 如果函数超过 40 行, 可以思索一下能不能在不影响程序结构的前提下对其进行分割. 即使一个长函数现在工作的非常好, 一旦有人对其修改, 有可能出现新的问题. 甚至导致难以发现的 bug. 使函数尽量简短, 便于他人阅读和修改代码. @@ -300,4 +301,4 @@ #. 为降低复杂性, 尽量不重载操作符, 模板, 标准类中使用时提供文档说明; #. 存取函数一般内联在头文件中; #. 声明次序: ``public`` -> ``protected`` -> ``private``; -#. 函数体尽量短小, 紧凑, 功能单一; \ No newline at end of file +#. 函数体尽量短小, 紧凑, 功能单一; diff --git a/google-cpp-styleguide/comments.rst b/google-cpp-styleguide/comments.rst index b46a61f..fecbfd4 100644 --- a/google-cpp-styleguide/comments.rst +++ b/google-cpp-styleguide/comments.rst @@ -1,12 +1,12 @@ 7. 注释 ------------- +------ 注释虽然写起来很痛苦, 但对保证代码可读性至关重要. 下面的规则描述了如何注释以及在哪儿注释. 当然也要记住: 注释固然很重要, 但最好的代码本身应该是自文档化. 有意义的类型名和变量名, 要远胜过要用注释解释的含糊不清的名字. 你写的注释是给代码读者看的: 下一个需要理解你的代码的人. 慷慨些吧, 下一个人可能就是你! 7.1. 注释风格 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 使用 ``//`` 或 ``/* */``, 统一就好. @@ -14,39 +14,41 @@ ``//`` 或 ``/* */`` 都可以; 但 ``//`` *更* 常用. 要在如何注释及注释风格上确保统一. 7.2. 文件注释 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 在每一个文件开头加入版权公告, 然后是文件内容描述. - + 法律公告和作者信息: + 每个文件都应该包含以下项, 依次是: - + - 版权声明 (比如, ``Copyright 2008 Google Inc.``) - + - 许可证. 为项目选择合适的许可证版本 (比如, Apache 2.0, BSD, LGPL, GPL) - + - 作者: 标识文件的原始作者. - + 如果你对原始作者的文件做了重大修改, 将你的信息添加到作者信息里. 这样当其他人对该文件有疑问时可以知道该联系谁. 文件内容: + 紧接着版权许可和作者信息之后, 每个文件都要用注释描述文件内容. - + 通常, ``.h`` 文件要对所声明的类的功能和用法作简单说明. ``.cc`` 文件通常包含了更多的实现细节或算法技巧讨论, 如果你感觉这些实现细节或算法技巧讨论对于理解 ``.h`` 文件有帮助, 可以该注释挪到 ``.h``, 并在 ``.cc`` 中指出文档在 ``.h``. - + 不要简单的在 ``.h`` 和 ``.cc`` 间复制注释. 这种偏离了注释的实际意义. .. _class-comments: 7.3. 类注释 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~ .. tip:: 每个类的定义都要附带一份注释, 描述类的功能和用法. .. code-block:: c++ - + // Iterates over the contents of a GargantuanTable. Sample usage: // GargantuanTable_Iterator* iter = table->NewIterator(); // for (iter->Seek("foo"); !iter->done(); iter->Next()) { @@ -56,33 +58,34 @@ class GargantuanTable_Iterator { ... }; - + 如果你觉得已经在文件顶部详细描述了该类, 想直接简单的来上一句 "完整描述见文件顶部" 也不打紧, 但务必确保有这类注释. 如果类有任何同步前提, 文档说明之. 如果该类的实例可被多线程访问, 要特别注意文档说明多线程环境下相关的规则和常量使用. 7.4. 函数注释 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 函数声明处注释描述函数功能; 定义处描述函数实现. - + 函数声明: + 注释位于声明之前, 对函数功能及用法进行描述. 注释使用叙述式 ("Opens the file") 而非指令式 ("Open the file"); 注释只是为了描述函数, 而不是命令函数做什么. 通常, 注释不会描述函数如何工作. 那是函数定义部分的事情. - + 函数声明处注释的内容: - + - 函数的输入输出. - 对类成员函数而言: 函数调用期间对象是否需要保持引用参数, 是否会释放这些参数. - 如果函数分配了空间, 需要由调用者释放. - 参数是否可以为 ``NULL``. - 是否存在函数使用上的性能隐患. - 如果函数是可重入的, 其同步前提是什么? - + 举例如下: - + .. code-block:: c++ - + // Returns an iterator for this table. It is the client's // responsibility to delete the iterator when it is done with it, // and it must not use the iterator once the GargantuanTable object @@ -98,32 +101,34 @@ // returned iterator, it will be faster to use NewIterator() // and avoid the extra seek. Iterator* GetIterator() const; - + 但也要避免罗罗嗦嗦, 或做些显而易见的说明. 下面的注释就没有必要加上 "returns false otherwise", 因为已经暗含其中了: - + .. code-block:: c++ - + // Returns true if the table cannot hold any more entries. bool IsTableFull(); - + 注释构造/析构函数时, 切记读代码的人知道构造/析构函数是干啥的, 所以 "destroys this object" 这样的注释是没有意义的. 注明构造函数对参数做了什么 (例如, 是否取得指针所有权) 以及析构函数清理了什么. 如果都是些无关紧要的内容, 直接省掉注释. 析构函数前没有注释是很正常的. 函数定义: + 每个函数定义时要用注释说明函数功能和实现要点. 比如说说你用的编程技巧, 实现的大致步骤, 或解释如此实现的理由, 为什么前半部分要加锁而后半部分不需要. - + *不要* 从 ``.h`` 文件或其他地方的函数声明处直接复制注释. 简要重述函数功能是可以的, 但注释重点要放在如何实现上. - + 7.5. 变量注释 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 通常变量名本身足以很好说明变量用途. 某些情况下, 也需要额外的注释说明. 类数据成员: + 每个类数据成员 (也叫实例变量或成员变量) 都应该用注释说明用途. 如果变量可以接受 ``NULL`` 或 ``-1`` 等警戒值, 须加以说明. 比如: - + .. code-block:: c++ - + private: // Keeps track of the total number of entries in the table. // Used to ensure we do not go over the limit. -1 means @@ -132,25 +137,26 @@ 全局变量: + 和数据成员一样, 所有全局变量也要注释说明含义及用途. 比如: - + .. code-block:: c++ - + // The total number of tests cases that we run through in this regression test. const int kNumTestCases = 6; - 7.6. 实现注释 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 对于代码中巧妙的, 晦涩的, 有趣的, 重要的地方加以注释. - + 代码前注释: + 巧妙或复杂的代码段前要加注释. 比如: - + .. code-block:: c++ - + // Divide result by two, taking into account that x // contains the carry from the add. for (int i = 0; i < result->size(); i++) { @@ -160,21 +166,22 @@ } 行注释: + 比较隐晦的地方要在行尾加入注释. 在行尾空两格进行注释. 比如: - + .. code-block:: c++ - + // If we have enough memory, mmap the data portion too. mmap_budget = max(0, mmap_budget - index_->length()); if (mmap_budget >= data_size_ && !MmapData(mmap_chunk_bytes, mlock)) return; // Error already logged. - + 注意, 这里用了两段注释分别描述这段代码的作用, 和提示函数返回时错误已经被记入日志. - + 如果你需要连续进行多行注释, 可以使之对齐获得更好的可读性: - + .. code-block:: c++ - + DoSomething(); // Comment here so the comments line up. DoSomethingElseThatIsLonger(); // Comment here so there are two spaces between // the code and the comment. @@ -184,31 +191,32 @@ } NULL, true/false, 1, 2, 3...: + 向函数传入 ``NULL``, 布尔值或整数时, 要注释说明含义, 或使用常量让代码望文知意. 例如, 对比: - + .. warning:: .. code-block:: c++ - + bool success = CalculateSomething(interesting_value, 10, false, NULL); // What are these arguments?? - - + + 和: - + .. code-block:: c++ - + bool success = CalculateSomething(interesting_value, 10, // Default base value. false, // Not the first time we're calling this. NULL); // No callback. - - + + 或使用常量或描述性变量: - + .. code-block:: c++ - + const int kDefaultBaseValue = 10; const bool kFirstTimeCalling = false; Callback *null_callback = NULL; @@ -218,60 +226,61 @@ NULL, true/false, 1, 2, 3...: null_callback); 不允许: + 注意 *永远不要* 用自然语言翻译代码作为注释. 要假设读代码的人 C++ 水平比你高, 即便他/她可能不知道你的用意: - + .. warning:: .. code-block:: c++ - + // 现在, 检查 b 数组并确保 i 是否存在, // 下一个元素是 i+1. ... // 天哪. 令人崩溃的注释. - + 7.7. 标点, 拼写和语法 -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~ .. tip:: 注意标点, 拼写和语法; 写的好的注释比差的要易读的多. - + 注释的通常写法是包含正确大小写和结尾句号的完整语句. 短一点的注释 (如代码行尾注释) 可以随意点, 依然要注意风格的一致性. 完整的语句可读性更好, 也可以说明该注释是完整的, 而不是一些不成熟的想法. 虽然被别人指出该用分号时却用了逗号多少有些尴尬, 但清晰易读的代码还是很重要的. 正确的标点, 拼写和语法对此会有所帮助. 7.8. TODO 注释 -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~ .. tip:: 对那些临时的, 短期的解决方案, 或已经够好但仍不完美的代码使用 ``TODO`` 注释. - + ``TODO`` 注释要使用全大写的字符串 ``TODO``, 在随后的圆括号里写上你的大名, 邮件地址, 或其它身份标识. 冒号是可选的. 主要目的是让添加注释的人 (也是可以请求提供更多细节的人) 可根据规范的 ``TODO`` 格式进行查找. 添加 ``TODO`` 注释并不意味着你要自己来修正. - + .. code-block:: c++ - + // TODO(kl@gmail.com): Use a "*" here for concatenation operator. // TODO(Zeke) change this to use relations. - + 如果加 ``TODO`` 是为了在 "将来某一天做某事", 可以附上一个非常明确的时间 "Fix by November 2005"), 或者一个明确的事项 ("Remove this code when all clients can handle XML responses."). 7.9. 弃用注释 +~~~~~~~~~~~ .. tip:: 通过弃用注释（``DEPRECATED`` comments）以标记某接口点（interface points）已弃用。 - - 您可以写上包含全大写的 ``DEPRECATED`` 的注释，以标记某接口为弃用状态。注释可以放在接口声明前，或者同一行。 - - 在 ``DEPRECATED`` 一词后，留下您的名字，邮箱地址以及括号补充。 - - 仅仅标记接口为 ``DEPRECATED`` 并不会让大家不约而同地弃用，您还得亲自主动修正调用点（callsites），或是找个帮手。 - - 修正好的代码应该不会再涉及弃用接口点了，着实改用新接口点。如果您不知从何下手，可以找标记弃用注释的当事人一起商量。 +您可以写上包含全大写的 ``DEPRECATED`` 的注释，以标记某接口为弃用状态。注释可以放在接口声明前，或者同一行。 + +在 ``DEPRECATED`` 一词后，留下您的名字，邮箱地址以及括号补充。 + +仅仅标记接口为 ``DEPRECATED`` 并不会让大家不约而同地弃用，您还得亲自主动修正调用点（callsites），或是找个帮手。 + +修正好的代码应该不会再涉及弃用接口点了，着实改用新接口点。如果您不知从何下手，可以找标记弃用注释的当事人一起商量。 译者 (YuleFox) 笔记 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ -1. 关于注释风格，很多 C++ 的 coders 更喜欢行注释, C coders 或许对块注释依然情有独钟, 或者在文件头大段大段的注释时使用块注释; -2. 文件注释可以炫耀你的成就, 也是为了捅了篓子别人可以找你; -3. 注释要言简意赅, 不要拖沓冗余, 复杂的东西简单化和简单的东西复杂化都是要被鄙视的; -4. 对于 Chinese coders 来说, 用英文注释还是用中文注释, it is a problem, 但不管怎样, 注释是为了让别人看懂, 难道是为了炫耀编程语言之外的你的母语或外语水平吗； -5. 注释不要太乱, 适当的缩进才会让人乐意看. 但也没有必要规定注释从第几列开始 (我自己写代码的时候总喜欢这样), UNIX/LINUX 下还可以约定是使用 tab 还是 space, 个人倾向于 space; -6. TODO 很不错, 有时候, 注释确实是为了标记一些未完成的或完成的不尽如人意的地方, 这样一搜索, 就知道还有哪些活要干, 日志都省了. +#. 关于注释风格，很多 C++ 的 coders 更喜欢行注释, C coders 或许对块注释依然情有独钟, 或者在文件头大段大段的注释时使用块注释; +#. 文件注释可以炫耀你的成就, 也是为了捅了篓子别人可以找你; +#. 注释要言简意赅, 不要拖沓冗余, 复杂的东西简单化和简单的东西复杂化都是要被鄙视的; +#. 对于 Chinese coders 来说, 用英文注释还是用中文注释, it is a problem, 但不管怎样, 注释是为了让别人看懂, 难道是为了炫耀编程语言之外的你的母语或外语水平吗； +#. 注释不要太乱, 适当的缩进才会让人乐意看. 但也没有必要规定注释从第几列开始 (我自己写代码的时候总喜欢这样), UNIX/LINUX 下还可以约定是使用 tab 还是 space, 个人倾向于 space; +#. TODO 很不错, 有时候, 注释确实是为了标记一些未完成的或完成的不尽如人意的地方, 这样一搜索, 就知道还有哪些活要干, 日志都省了. diff --git a/google-cpp-styleguide/contents.rst b/google-cpp-styleguide/contents.rst index d109ec1..a74e019 100644 --- a/google-cpp-styleguide/contents.rst +++ b/google-cpp-styleguide/contents.rst @@ -2,9 +2,8 @@ .. _cpp_contents: - C++ 风格指南 - 内容目录 -========================== +==================== .. contents:: :backlinks: none diff --git a/google-cpp-styleguide/end.rst b/google-cpp-styleguide/end.rst index c94fa89..e3c6dfc 100644 --- a/google-cpp-styleguide/end.rst +++ b/google-cpp-styleguide/end.rst @@ -1,5 +1,5 @@ 10. 结束语 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~ .. tip:: diff --git a/google-cpp-styleguide/exceptions.rst b/google-cpp-styleguide/exceptions.rst index e4d47dd..255b399 100644 --- a/google-cpp-styleguide/exceptions.rst +++ b/google-cpp-styleguide/exceptions.rst @@ -1,43 +1,43 @@ 9. 规则特例 ----------------- +--------- 前面说明的编程习惯基本都是强制性的. 但所有优秀的规则都允许例外, 这里就是探讨这些特例. 9.1. 现有不合规范的代码 -~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ .. tip:: 对于现有不符合既定编程风格的代码可以网开一面. - + 当你修改使用其他风格的代码时, 为了与代码原有风格保持一致可以不使用本指南约定. 如果不放心可以与代码原作者或现在的负责人员商讨, 记住, *一致性* 包括原有的一致性. .. _windows-code: 9.2. Windows 代码 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: Windows 程序员有自己的编程习惯, 主要源于 Windows 头文件和其它 Microsoft 代码. 我们希望任何人都可以顺利读懂你的代码, 所以针对所有平台的 C++ 编程只给出一个单独的指南. - + 如果你习惯使用 Windows 编码风格, 这儿有必要重申一下某些你可能会忘记的指南: - 不要使用匈牙利命名法 (比如把整型变量命名成 ``iNum``). 使用 Google 命名约定, 包括对源文件使用 ``.cc`` 扩展名. - + - Windows 定义了很多原生类型的同义词 (YuleFox 注: 这一点, 我也很反感), 如 ``DWORD``, ``HANDLE`` 等等. 在调用 Windows API 时这是完全可以接受甚至鼓励的. 但还是尽量使用原有的 C++ 类型, 例如, 使用 ``const TCHAR *`` 而不是 ``LPCTSTR``. - + - 使用 Microsoft Visual C++ 进行编译时, 将警告级别设置为 3 或更高, 并将所有 warnings 当作 errors 处理. - + - 不要使用 ``#pragma once``; 而应该使用 Google 的头文件保护规则. 头文件保护的路径应该相对于项目根目录 (yospaly 注: 如 ``#ifndef SRC_DIR_BAR_H_``, 参考 :ref:`#define 保护 ` 一节). - + - 除非万不得已, 不要使用任何非标准的扩展, 如 ``#pragma`` 和 ``__declspec``. 允许使用 ``__declspec(dllimport)`` 和 ``__declspec(dllexport)``; 但你必须通过宏来使用, 比如 ``DLLIMPORT`` 和 ``DLLEXPORT``, 这样其他人在分享使用这些代码时很容易就去掉这些扩展. - + 在 Windows 上, 只有很少的一些情况下, 我们可以偶尔违反规则: - 通常我们 :ref:`禁止使用多重继承 `, 但在使用 COM 和 ATL/WTL 类时可以使用多重继承. 为了实现 COM 或 ATL/WTL 类/接口, 你可能不得不使用多重实现继承. - + - 虽然代码中不应该使用异常, 但是在 ATL 和部分 STL（包括 Visual C++ 的 STL) 中异常被广泛使用. 使用 ATL 时, 应定义 ``_ATL_NO_EXCEPTIONS`` 以禁用异常. 你要研究一下是否能够禁用 STL 的异常, 如果无法禁用, 启用编译器异常也可以. (注意这只是为了编译 STL, 自己代码里仍然不要含异常处理.) - + - 通常为了利用头文件预编译, 每个每个源文件的开头都会包含一个名为 ``StdAfx.h`` 或 ``precompile.h`` 的文件. 为了使代码方便与其他项目共享, 避免显式包含此文件 (``precompile.cc``), 使用 ``/FI`` 编译器选项以自动包含. - + - 资源头文件通常命名为 ``resource.h``, 且只包含宏的, 不需要遵守本风格指南. - \ No newline at end of file + diff --git a/google-cpp-styleguide/formatting.rst b/google-cpp-styleguide/formatting.rst index 8970edc..25df5fb 100644 --- a/google-cpp-styleguide/formatting.rst +++ b/google-cpp-styleguide/formatting.rst @@ -1,5 +1,5 @@ 8. 格式 ------------- +------ 代码风格和格式确实比较随意, 但一个项目中所有人遵循同一风格是非常容易的. 个体未必同意下述每一处格式规则, 但整个项目服从统一的编程风格是很重要的, 只有这样才能让所有人能很轻松的阅读和理解代码. @@ -8,40 +8,40 @@ .. _line-length: 8.1. 行长度 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~ .. tip:: 每一行代码字符数不超过 80. - + 我们也认识到这条规则是有争议的, 但很多已有代码都已经遵照这一规则, 我们感觉一致性更重要. 优点: 提倡该原则的人主张强迫他们调整编辑器窗口大小很野蛮. 很多人同时并排开几个代码窗口, 根本没有多余空间拉伸窗口. 大家都把窗口最大尺寸加以限定, 并且 80 列宽是传统标准. 为什么要改变呢? - + 缺点: 反对该原则的人则认为更宽的代码行更易阅读. 80 列的限制是上个世纪 60 年代的大型机的古板缺陷; 现代设备具有更宽的显示屏, 很轻松的可以显示更多代码. - + 结论: 80 个字符是最大值. - + 特例: - + - 如果一行注释包含了超过 80 字符的命令或 URL, 出于复制粘贴的方便允许该行超过 80 字符. - 包含长路径的 ``#include`` 语句可以超出80列. 但应该尽量避免. - - :ref:`头文件保护 ` 可以无视该原则. - + - :ref:`头文件保护 ` 可以无视该原则. + 8.2. 非 ASCII 字符 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: 尽量不使用非 ASCII 字符, 使用时必须使用 UTF-8 编码. - + 即使是英文, 也不应将用户界面的文本硬编码到源代码中, 因此非 ASCII 字符要少用. 特殊情况下可以适当包含此类字符. 如, 代码分析外部数据文件时, 可以适当硬编码数据文件中作为分隔符的非 ASCII 字符串; 更常见的是 (不需要本地化的) 单元测试代码可能包含非 ASCII 字符串. 此类情况下, 应使用 UTF-8 编码, 因为很多工具都可以理解和处理 UTF-8 编码. -十六进制编码也可以, 能增强可读性的情况下尤其鼓励 —— 比如 ``"\xEF\xBB\xBF"`` 在 Unicode 中是 *零宽度 无间断* 的间隔符号, 如果不用十六进制直接放在 UTF-8 格式的源文件中, 是看不到的. +十六进制编码也可以, 能增强可读性的情况下尤其鼓励 —— 比如 ``"\xEF\xBB\xBF"`` 在 Unicode 中是 *零宽度 无间断* 的间隔符号, 如果不用十六进制直接放在 UTF-8 格式的源文件中, 是看不到的. (yospaly 注: ``"\xEF\xBB\xBF"`` 通常用作 UTF-8 with BOM 编码标记) @@ -49,44 +49,43 @@ 别用 C++11 的 ``char16_t`` 和 ``char32_t``, 它们和 UTF-8 文本没有关系，``wchar_t`` 同理，除非您写的代码要调用 Windows API, 后者有用到 ``wchar_t`` 扩展。 - 8.3. 空格还是制表位 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: 只使用空格, 每次缩进 2 个空格. - + 我们使用空格缩进. 不要在代码中使用制符表. 你应该设置编辑器将制符表转为空格. 8.4. 函数声明与定义 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: 返回类型和函数名在同一行, 参数也尽量放在同一行，如果放不下就对形参分行。 - + 函数看上去像这样: .. code-block:: c++ - + ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { DoSomething(); ... } - + 如果同一行文本太多, 放不下所有参数: .. code-block:: c++ - + ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2, Type par_name3) { DoSomething(); ... } - + 甚至连第一个参数都放不下: .. code-block:: c++ - + ReturnType LongClassName::ReallyReallyReallyLongFunctionName( Type par_name1, // 4 space indent Type par_name2, @@ -94,11 +93,11 @@ DoSomething(); // 2 space indent ... } - + 注意以下几点: - 如果返回类型和函数名在一行放不下，分行。 - + - 如果返回类型那个与函数声明或定义分行了，不要缩进。 - 左圆括号总是和函数名在同一行; @@ -120,51 +119,50 @@ - 缺省缩进为 2 个空格; - 换行后的参数保持 4 个空格的缩进; - + 如果有些参数没有用到, 在函数定义处将参数名注释起来: .. code-block:: c++ - + // Always have named parameters in interfaces. class Shape { public: virtual void Rotate(double radians) = 0; } - + // Always have named parameters in the declaration. class Circle : public Shape { public: virtual void Rotate(double radians); } - + // Comment out unused named parameters in definitions. void Circle::Rotate(double /*radians*/) {} - + .. warning:: .. code-block:: c++ - + // Bad - if someone wants to implement later, it's not clear what the // variable means. void Circle::Rotate(double) {} - 8.5. Lambda 表达式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ .. tip:: 其它函数怎么格式化形参和函数体，Lambda 表达式就怎么格式化；捕获列表同理。 - + 若用引用捕获，在变量名和 ``&`` 之间不留空格。 - + .. code-block:: c++ - + int x = 0; auto add_to_x = [&x](int n) { x += n; }; - + 短 lambda 就写得和内联函数一样。 - + .. code-block:: c++ - + std::set blacklist = {7, 8, 9}; std::vector digits = {3, 9, 1, 8, 4, 7, 1}; digits.erase(std::remove_if(digits.begin(), digits.end(), [&blacklist](int i) { @@ -172,30 +170,29 @@ }), digits.end()); - 8.6. 函数调用 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 要么一行写完函数调用，要么在圆括号里对参数分行，要么参数另起一行且缩进四格。如果没有其它顾虑的话，尽可能精简行数，比如把多个参数适当地放在同一行里。 - + 函数调用遵循如下形式： .. code-block:: c++ - + bool retval = DoSomething(argument1, argument2, argument3); - + 如果同一行放不下，可断为多行，后面每一行都和第一个实参对齐，左圆括号后和右圆括号前不要留空格： .. code-block:: c++ - + bool retval = DoSomething(averyveryveryverylongargument1, argument2, argument3); - + 参数也可以放在次行，缩进四格： .. code-block:: c++ - + if (...) { ... ... @@ -206,48 +203,49 @@ } 把多个参数放在同一行，是为了减少函数调用所需的行数，除非影响到可读性。有人认为把每个参数都独立成行，不仅更好读，而且方便编辑参数。不过，比起所谓的参数编辑，我们更看重可读性，且后者比较好办： - + 如果一些参数本身就是略复杂的表达式，且降低了可读性。那么可以直接创建临时变量描述该表达式，并传递给函数： - + .. code-block:: c++ - + int my_heuristic = scores[x] * y + bases[x]; bool retval = DoSomething(my_heuristic, x, y, z); - + 或者放着不管，补充上注释： - + .. code-block:: c++ - + bool retval = DoSomething(scores[x] * y + bases[x], // Score heuristic. x, y, z); - + 如果某参数独立成行，对可读性更有帮助的话，就这么办。 - + 此外，如果一系列参数本身就有一定的结构，可以酌情地按其结构来决定参数格式： - + .. code-block:: c++ - + // Transform the widget by a 3x3 matrix. my_widget.Transform(x1, x2, x3, y1, y2, y3, z1, z2, z3); - +.. _braced-initializer-list-format + 8.7. 列表初始化格式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: - 您平时怎么格式化函数调用，就怎么格式化列表初始化。 - + 您平时怎么格式化函数调用，就怎么格式化:ref:`braced_initializer_list`。 + 如果列表初始化伴随着名字，比如类型或变量名，您可以当名字是函数、{} 是函数调用的括号来格式化它。反之，就当它有个长度为零的名字。 - + .. code-block:: c++ - + // Examples of braced init list on a single line. return {foo, bar}; functioncall({foo, bar}); pair p{foo, bar}; - + // When you have to wrap. SomeFunction( {"assume a zero-length name before {"}, @@ -269,99 +267,98 @@ {interiorwrappinglist, interiorwrappinglist2}}; - 8.8. 条件语句 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 倾向于不在圆括号内使用空格. 关键字 ``if`` 和 ``else`` 另起一行. - + 对基本条件语句有两种可以接受的格式. 一种在圆括号和条件之间有空格, 另一种没有. 最常见的是没有空格的格式. 哪种都可以, 但 *保持一致性*. 如果你是在修改一个文件, 参考当前已有格式. 如果是写新的代码, 参考目录下或项目中其它文件. 还在徘徊的话, 就不要加空格了. .. code-block:: c++ - + if (condition) { // no spaces inside parentheses ... // 2 space indent. } else { // The else goes on the same line as the closing brace. ... } - + 如果你更喜欢在圆括号内部加空格: .. code-block:: c++ - + if ( condition ) { // spaces inside parentheses - rare ... // 2 space indent. } else { // The else goes on the same line as the closing brace. ... } - + 注意所有情况下 ``if`` 和左圆括号间都有个空格. 右圆括号和左大括号之间也要有个空格: .. warning:: - + .. code-block:: c++ - + if(condition) // Bad - space missing after IF. if (condition){ // Bad - space missing before {. if(condition){ // Doubly bad. - + .. code-block:: c++ - + if (condition) { // Good - proper space after IF and before {. - + 如果能增强可读性, 简短的条件语句允许写在同一行. 只有当语句简单并且没有使用 ``else`` 子句时使用: .. code-block:: c++ - + if (x == kFoo) return new Foo(); if (x == kBar) return new Bar(); - + 如果语句有 ``else`` 分支则不允许: .. warning:: - + .. code-block:: c++ - + // Not allowed - IF statement on one line when there is an ELSE clause if (x) DoThis(); else DoThat(); - + 通常, 单行语句不需要使用大括号, 如果你喜欢用也没问题; 复杂的条件或循环语句用大括号可读性会更好. 也有一些项目要求 ``if`` 必须总是使用大括号: .. code-block:: c++ - + if (condition) DoSomething(); // 2 space indent. - + if (condition) { DoSomething(); // 2 space indent. } - + 但如果语句中某个 ``if-else`` 分支使用了大括号的话, 其它分支也必须使用: .. warning:: - + .. code-block:: c++ - + // Not allowed - curly on IF but not ELSE if (condition) { foo; } else bar; - + // Not allowed - curly on ELSE but not IF if (condition) foo; else { bar; } - - + + .. code-block:: c++ - + // Curly braces around both IF and ELSE required because // one of the clauses used braces. if (condition) { @@ -370,19 +367,18 @@ bar; } - 8.9. 循环和开关选择语句 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ .. tip:: ``switch`` 语句可以使用大括号分段，以表明 cases 之间不是连在一起的。在单语句循环里，括号可用可不用。空循环体应使用 ``{}`` 或 ``continue``. - + ``switch`` 语句中的 ``case`` 块可以使用大括号也可以不用, 取决于你的个人喜好. 如果用的话, 要按照下文所述的方法. 如果有不满足 ``case`` 条件的枚举值, ``switch`` 应该总是包含一个 ``default`` 匹配 (如果有输入值没有 case 去处理, 编译器将报警). 如果 ``default`` 应该永远执行不到, 简单的加条 ``assert``: .. code-block:: c++ - + switch (var) { case 0: { // 2 space indent ... // 4 space indent @@ -400,41 +396,40 @@ 在单语句循环里，括号可用可不用： .. code-block:: c++ - + for (int i = 0; i < kSomeNumber; ++i) printf("I love you\n"); - + for (int i = 0; i < kSomeNumber; ++i) { printf("I take it back\n"); } - + 空循环体应使用 ``{}`` 或 ``continue``, 而不是一个简单的分号. .. code-block:: c++ - + while (condition) { // Repeat test until it returns false. } for (int i = 0; i < kSomeNumber; ++i) {} // Good - empty body. while (condition) continue; // Good - continue indicates no logic. - + .. warning:: - + .. code-block:: c++ - + while (condition); // Bad - looks like part of do/while loop. - 8.10. 指针和引用表达式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ .. tip:: 句点或箭头前后不要有空格. 指针/地址操作符 (``*, &``) 之后不能有空格. - + 下面是指针和引用表达式的正确使用范例: .. code-block:: c++ - + x = *p; p = &x; x = r.y; @@ -443,81 +438,80 @@ 注意:啊 - 在访问成员时, 句点或箭头前后没有空格. - 指针操作符 ``*`` 或 ``&`` 后没有空格. - + 在声明指针变量或参数时, 星号与类型或变量名紧挨都可以: .. code-block:: c++ - + // These are fine, space preceding. char *c; const string &str; - + // These are fine, space following. char* c; // but remember to do "char* c, *d, *e, ...;"! const string& str; - + .. warning:: - + .. code-block:: c++ - + char * c; // Bad - spaces on both sides of * const string & str; // Bad - spaces on both sides of & - + 在单个文件内要保持风格一致, 所以, 如果是修改现有文件, 要遵照该文件的风格. 8.11. 布尔表达式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 如果一个布尔表达式超过 :ref:`标准行宽 `, 断行方式要统一一下. - + 下例中, 逻辑与 (``&&``) 操作符总位于行尾: .. code-block:: c++ - + if (this_one_thing > this_other_thing && a_third_thing == a_fourth_thing && yet_another & last_one) { ... } - + 注意, 上例的逻辑与 (``&&``) 操作符均位于行尾. 这格式在 Google 里很常见，您要把所有操作符放在开头也可以。可以考虑额外插入圆括号, 合理使用的话对增强可读性是很有帮助的. 此外直接用符号形式的操作符，比如 ``&&`` 和 ``~``, 不要用词语形式的 ``and`` 和 ``compl``. - 8.12. 函数返回值 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: ``return`` 表达式里时没必要都用圆括号。 - + 在 ``return expr;`` 里就用圆括号，当且只当您会在 ``x = epr;`` 用上它们（acgtyrant 注：字面上的意思就是这样，我也不知怎么理解，只能直译了；我猜意为「当且只当您用该函数的返回值赋值给某变量」）。 - + 函数返回时不要使用圆括号: .. code-block:: c++ - + return result; // No parentheses in the simple case. // Parentheses OK to make a complex expression more readable. return (some_long_condition && another_condition); - + .. warning:: - + .. code-block:: c++ - + return (value); // You wouldn't write var = (value); return(result); // return is not a function! - + 8.13. 变量及数组初始化 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ .. tip:: 用 ``=``, ``()`` 和 ``{}`` 均可. - + 您可以用 ``=``, ``()`` 和 ``{}``, 以下都对： .. code-block:: c++ - + int x = 3; int x(3); int x{3}; @@ -528,28 +522,27 @@ 请务必小心列表初始化 {...} 用 ``std::initializer_list`` 构造函数初始化出的类型。非空列表初始化就会优先调用 ``std::initializer_list``, 不过空列表初始化除外，后者原则上会调用默认构造函数。为了强制禁用 ``std::initializer_list`` 构造函数，请改用括号。 .. code-block:: c++ - + vector v(100, 1); // A vector of 100 1s. vector v{100, 1}; // A vector of 100, 1. 此外，列表初始化不允许整型类型的四舍五入，这可以用来避免一些类型上的编程失误。 .. code-block:: c++ - + int pi(3.14); // OK -- pi == 3. int pi{3.14}; // Compile error: narrowing conversion. - 8.14. 预处理指令 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 预处理指令不要缩进, 从行首开始. - + 即使预处理指令位于缩进代码块中, 指令也应从行首开始. .. code-block:: c++ - + // Good - directives at beginning of line if (lopsided_score) { #if DISASTER_PENDING // Correct -- Starts at beginning of line @@ -557,11 +550,11 @@ #endif BackToNormal(); } - + .. warning:: - + .. code-block:: c++ - + // Bad - indented directives if (lopsided_score) { #if DISASTER_PENDING // Wrong! The "#if" should be at beginning of line @@ -570,69 +563,68 @@ BackToNormal(); } - 8.15. 类格式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 访问控制块的声明依次序是 ``public:``, ``protected:``, ``private:``, 每次缩进 1 个空格. - + 类声明 (对类注释不了解的话, 参考 :ref:`类注释 `) 的基本格式如下: .. code-block:: c++ - + class MyClass : public OtherClass { public: // Note the 1 space indent! MyClass(); // Regular 2 space indent. explicit MyClass(int var); ~MyClass() {} - + void SomeFunction(); void SomeFunctionThatDoesNothing() { } - + void set_some_var(int var) { some_var_ = var; } int some_var() const { return some_var_; } - + private: bool SomeInternalFunction(); - + int some_var_; int some_other_var_; DISALLOW_COPY_AND_ASSIGN(MyClass); }; - + 注意事项: - 所有基类名应在 80 列限制下尽量与子类名放在同一行. - + - 关键词 ``public:``, ``protected:``, ``private:`` 要缩进 1 个空格. - + - 除第一个关键词 (一般是 ``public``) 外, 其他关键词前要空一行. 如果类比较小的话也可以不空. - + - 这些关键词后不要保留空行. - + - ``public`` 放在最前面, 然后是 ``protected``, 最后是 ``private``. - + - 关于声明顺序的规则请参考 :ref:`声明顺序 ` 一节. - + 8.16. 初始化列表 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 构造函数初始化列表放在同一行或按四格缩进并排几行. - + 下面两种初始化列表方式都可以接受: - + .. code-block:: c++ - + // When it all fits on one line: MyClass::MyClass(int var) : some_var_(var), some_other_var_(var + 1) { - + 或 - + .. code-block:: c++ - + // When it requires multiple lines, indent 4 spaces, putting the colon on // the first initializer line: MyClass::MyClass(int var) @@ -642,17 +634,17 @@ DoSomething(); ... } - + 8.17. 名字空间格式化 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ .. tip:: 名字空间内容不缩进. - + :ref:`名字空间 ` 不要增加额外的缩进层次, 例如: .. code-block:: c++ - + namespace { void foo() { // Correct. No extra indentation within namespace. @@ -660,13 +652,13 @@ } } // namespace - + 不要缩进名字空间: .. warning:: - + .. code-block:: c++ - + namespace { // Wrong. Indented when it should not be. @@ -675,25 +667,23 @@ } } // namespace - + 声明嵌套命名空间时，每命名空间都独立成行。 .. code-block:: c++ - + namespace foo { namespace bar { - 8.18. 水平留白 -~~~~~~~~~~~~~~~~~~~~~~~~~~ - +~~~~~~~~~~~~ .. tip:: 水平留白的使用因地制宜. 永远不要在行尾添加没意义的留白. - + 常规: .. code-block:: c++ - + void f(bool b) { // Open braces should always have a space before them. ... int i = 0; // Semicolons usually have no space before them. @@ -707,14 +697,13 @@ Foo(int b) : Bar(), baz_(b) {} // No spaces inside empty braces. void Reset() { baz_ = 0; } // Spaces separating braces from implementation. ... - - 添加冗余的留白会给其他人编辑时造成额外负担. 因此, 行尾不要留空格. 如果确定一行代码已经修改完毕, 将多余的空格去掉; 或者在专门清理空格时去掉（确信没有其他人在处理). (yospaly 注: 现在大部分代码编辑器稍加设置后, 都支持自动删除行首/行尾空格, 如果不支持, 考虑换一款编辑器或 IDE) + 添加冗余的留白会给其他人编辑时造成额外负担. 因此, 行尾不要留空格. 如果确定一行代码已经修改完毕, 将多余的空格去掉; 或者在专门清理空格时去掉（确信没有其他人在处理). (yospaly 注: 现在大部分代码编辑器稍加设置后, 都支持自动删除行首/行尾空格, 如果不支持, 考虑换一款编辑器或 IDE) 循环和条件语句: .. code-block:: c++ - + if (b) { // Space after the keyword in conditions and loops. } else { // Spaces around else. } @@ -731,51 +720,50 @@ case 1: // No space before colon in a switch case. ... case 2: break; // Use a space after a colon if there's code after it. - + 操作符: .. code-block:: c++ - + // Assignment operators always have spaces around them. x = 0; - + // Other binary operators usually have spaces around them, but it's // OK to remove spaces around factors. Parentheses should have no // internal padding. v = w * x + y / z; v = w*x + y/z; v = w * (x + z); - + // No spaces separating unary operators and their arguments. x = -5; ++x; if (x && !y) ... - 模板和转换: .. code-block:: c++ - + // No spaces inside the angle brackets (< and >), before // <, or between >( in a cast vector x; y = static_cast(x); - + // Spaces between type and pointer are OK, but be consistent. vector x; set> x; // Permitted in C++11 code. set > x; // C++03 required a space in > >. - + // You may optionally use symmetric spacing in < <. set< list > x; 8.19. 垂直留白 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ .. tip:: 垂直留白越少越好. - + 这不仅仅是规则而是原则问题了: 不在万不得已, 不要使用空行. 尤其是: 两个函数定义之间的空行不要超过 2 行, 函数体首尾不要留空行, 函数体中也不要随意添加空行. 基本原则是: 同一屏可以显示的代码越多, 越容易理解程序的控制流. 当然, 过于密集的代码块和过于疏松的代码块同样难看, 取决于你的判断. 但通常是垂直留白越少越好. @@ -785,11 +773,10 @@ * 函数体内开头或结尾的空行可读性微乎其微。 * 在多重 if-else 块里加空行或许有点可读性。 - 译者 (YuleFox) 笔记 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~ -0. 对于代码格式, 因人, 系统而异各有优缺点, 但同一个项目中遵循同一标准还是有必要的; +*. 对于代码格式, 因人, 系统而异各有优缺点, 但同一个项目中遵循同一标准还是有必要的; 1. 行宽原则上不超过 80 列, 把 22 寸的显示屏都占完, 怎么也说不过去; 2. 尽量不使用非 ASCII 字符, 如果使用的话, 参考 UTF-8 格式 (尤其是 UNIX/Linux 下, Windows 下可以考虑宽字符), 尽量不将字符串常量耦合到代码中, 比如独立出资源文件, 这不仅仅是风格问题了; 3. UNIX/Linux 下无条件使用空格, MSVC 的话使用 Tab 也无可厚非; @@ -802,12 +789,12 @@ 10. 水平/垂直留白不要滥用, 怎么易读怎么来. 11. 关于 UNIX/Linux 风格为什么要把左大括号置于行尾 (``.cc`` 文件的函数实现处, 左大括号位于行首), 我的理解是代码看上去比较简约, 想想行首除了函数体被一对大括号封在一起之外, 只有右大括号的代码看上去确实也舒服; Windows 风格将左大括号置于行首的优点是匹配情况一目了然. -译者（acgtyrant）笔记： -~~~~~~~~~~~~~~~~~~~~~~ +译者（acgtyrant）笔记 +~~~~~~~~~~~~~~~~~~~ * 80 行限制事实上有助于避免代码可读性失控，比如超多重嵌套块，超多重函数调用等等。 * Linux 上设置好了 Locale 就几乎一劳永逸设置好所有开发环境的编码，不像奇葩的 Windows. * Google 强调有一对 if-else 时，不论有没有嵌套，都要有大括号。Apple 正好`有栽过跟头 `_. -* 其实我主张指针／地址操作符与变量名紧邻，``int* a, b`` vs ``int *a, b``, 新手会误以为前者的 ``b`` 是 ``int *`` 变量，但后者就不一样了，高下立判。 +* 其实我主张指针／地址操作符与变量名紧邻，``int* a, b`` vs ``int *a, b``, 新手会误以为前者的 ``b`` 是 ``int *`` 变量，但后者就不一样了，高下立判。 * 在这风格指南里我才刚知道 C++ 原来还有所谓的 `Alternative operator representations `_, 大概没人用吧。 * 事实上，如果您熟悉英语本身的书写规则，就会发现该风格指南在格式上的规定与英语语法相当一脉相承。比如普通标点符号和单词后面还有文本的话，总会留一个空格；特殊符号与单词之间就不用留了，比如 ``if (true)`` 中的圆括号与 ``true``. diff --git a/google-cpp-styleguide/headers.rst b/google-cpp-styleguide/headers.rst index 6ddd439..bbcf594 100644 --- a/google-cpp-styleguide/headers.rst +++ b/google-cpp-styleguide/headers.rst @@ -1,5 +1,5 @@ 1. 头文件 ------------- +-------- 通常每一个 ``.cc`` 文件都有一个对应的 ``.h`` 文件. 也有一些常见例外, 如单元测试代码和只包含 ``main()`` 函数的 ``.cc`` 文件. @@ -7,26 +7,29 @@ 下面的规则将引导你规避使用头文件时的各种陷阱. +.. _self-contained headers: + 1.1. Self-contained 头文件 +~~~~~~~~~~~~~~~~~~~~~~~~~ -头文件应该能够自给自足（self-contained），以 ``in.h`` 结尾。至于用来插入文本的文件，说到底它们并不是头文件，所以应以 ``.inc`` 结尾。 +.. tip:: + 头文件应该能够自给自足（self-contained），以 ``in.h`` 结尾。至于用来插入文本的文件，说到底它们并不是头文件，所以应以 ``.inc`` 结尾。 -所有头文件要能够自给自足。换言之，用户和重构工具不需要为特别场合而包含额外的头文件。详言之，一个头文件要有 #define 保护，统统包含它所需要的其它头文件，也不要求定义任何特别 symbols. +所有头文件要能够自给自足。换言之，用户和重构工具不需要为特别场合而包含额外的头文件。详言之，一个头文件要有 :ref:`define-guard`，统统包含它所需要的其它头文件，也不要求定义任何特别 symbols. 不过有一个例外，即一个文件并不是 self-contained 的，而是用来安插到代码某处里，特别是要安插多次的时候。或者，文件内容实际上是其它头文件的特定平台（platform-specific）扩展部分。这些文件就要用 ``.inc`` 文件扩展名。 如果 ``.h`` 文件声明了一个模板或内联函数，同时也在该文件加以定义。凡是有用到这些的 ``.cc`` 文件，就得统统包含该头文件，否则程序可能会在构建中链接失败。现在不要把这些定义放到分离的 -inl.h 文件里了（译者注：过去该规范曾提倡把定义放到 -inl.h 里过）。 -As an exception, a function template that is explicitly instantiated for all relevant sets of template arguments, or that is a private member of a class, may be defined in the only .cc file that instantiates the template. +As an exception, a function template that is explicitly instantiated for all relevant sets of template arguments, or that is a private member of a class, may be defined in the only .cc file that instantiates the template. TODO - -.. _define_guard: +.. _define-guard: 1.2. #define 保护 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: - 所有头文件都应该使用 ``#define`` 防止头文件被多重包含, 命名格式当是: ``___H_`` + 所有头文件都应该使用 ``#define`` 防止头文件被多重包含, 命名格式当是: ``___H_`` 为保证唯一性, 头文件的命名应该依据所在项目源代码树的全路径. 例如, 项目 ``foo`` 中的头文件 ``foo/src/bar/baz.h`` 可按如下方式保护: @@ -36,18 +39,19 @@ As an exception, a function template that is explicitly instantiated for all rel #define FOO_BAR_BAZ_H_ … #endif // FOO_BAR_BAZ_H_ - -.. _forward_declarations: + +.. _forward-declarations: 1.3. 前向声明 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ -您可以靠前置声明来避免多余的 ``#includes``. +.. tip:: + 您可以靠前置声明来避免多余的 ``#includes``. 定义： 所谓「前向声明」（forward declaration）是类，函数和模板的纯粹声明，没伴随着其定义。代码中用到了哪些 symbols, 往往可以用其前向声明来代替对应的 ``#inclues``. - + 优点： * 多余的 ``#includes`` 会害得编译器花费不少时间展开更多文件，处理大量输入。 @@ -59,26 +63,25 @@ As an exception, a function template that is explicitly instantiated for all rel * 很难判断什么时候该用前向声明，什么时候该用 ``#includes``, 特别是涉及隐式转换运算符的时候。极端情况下，用前向声明代替 ``includes`` 甚至都会暗暗地改变代码的含义。 * 前向声明了不少来自头文件的 symbol 时，就会比单单 ``includes`` 一行冗长。 * 前向声明函数或模板有时会害得头文件开发者难以轻易变动其 API. 就像扩大形参类型，加个自带默认参数的模板形参等等。 - * 前向声明来自命名空间 ``std::` 的 symbol 时，其行为为定义。 + * 前向声明来自命名空间 ``std::` 的 symbol 时，其行为未定义。 * 仅仅为了能前向声明而重构代码（比如用指针成员代替对象成员），后者会变慢且复杂起来。 * 还没有实践证实前向声明的优越性。 -决定： +结论： * 函数：用 ``#include``. * 类模板：优先用 ``#includes``. * 类：用前向声明固然不错，但小心点。若说不定，还是用 ``#includes`` 好了。 * 千万别为了避免 ``includes`` 而把数据成员改成指针。 -至于什么时候包含头文件，参见 :ref:```#include`` 的路径及顺序`。 +至于什么时候包含头文件，参见 :ref:`name-and-order-of-includes`。 .. _inline-functions: 1.4. 内联函数 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: - 只有当函数只有 10 行甚至更少时才将其定义为内联函数. 定义: @@ -96,14 +99,13 @@ As an exception, a function template that is explicitly instantiated for all rel 结论: 一个较为合理的经验准则是, 不要内联超过 10 行的函数. 谨慎对待析构函数, 析构函数往往比其表面看起来要更长, 因为有隐含的成员和基类析构函数被调用! - + 另一个实用的经验准则: 内联那些包含循环或 ``switch`` 语句的函数常常是得不偿失 (除非在大多数情况下, 这些循环或 ``switch`` 语句从不被执行). - + 有些函数即使声明为内联的也不一定会被编译器内联, 这点很重要; 比如虚函数和递归函数就不会被正常内联. 通常, 递归函数不应该声明成内联函数.（YuleFox 注: 递归调用堆栈的展开并不像循环那么简单, 比如递归层数在编译时可能是未知的, 大多数编译器都不支持内联递归函数). 虚函数内联的主要原因则是想把它的函数体放在类定义内, 为了图个方便, 抑或是当作文档描述其行为, 比如精短的存取函数. - 1.5. 函数参数的顺序 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: 定义函数时, 参数顺序依次为: 输入参数, 然后是输出参数. @@ -112,8 +114,10 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 这条规则并不需要严格遵守. 输入/输出两用参数 (通常是类/结构体变量) 把事情变得复杂, 为保持和相关函数的一致性, 你有时不得不有所变通. +.. _name-and-order-of-includes + 1.6. ``#include`` 的路径及顺序 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. tip:: 使用标准的头文件包含顺序可增强可读性, 避免隐藏依赖: 相关头文件, C 库, C++ 库, 其他库的 `.h`, 本项目内的 `.h`. @@ -121,7 +125,7 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 项目内头文件应按照项目源代码目录树结构排列, 避免使用 UNIX 特殊的快捷目录 ``.`` (当前目录) 或 ``..`` (上级目录). 例如, ``google-awesome-project/src/base/logging.h`` 应该按如下方式包含: .. code-block:: c++ - + #include “base/logging.h” 又如, ``dir/foo.cc`` 的主要作用是实现或测试 ``dir2/foo2.h`` 的功能, ``foo.cc`` 中包含头文件的次序如下: @@ -138,12 +142,12 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 按字母顺序对头文件包含进行二次排序是不错的主意 (yospaly 译注: 之前已经按头文件类别排过序了). -您所依赖的 symbols 被哪些头文件所定义，您就应该包含（include）哪些头文件，forward declaration 情况除外。比如您要用到 ``bar.h`` 中的某个 symbol, 哪怕您所包含的 ``foo.h`` 已经包含了 ``bar.h``, 也照样得包含 ``bar.h``, 除非 ``foo.h`` 有明确说明它会自动向您提供 ``bar.h`` 中的 symbol. 不过，凡是 cc 文件所对应的「相关头文件」已经包含的，就不用再重复包含进其 cc 文件里面了，就像 ``foo.cc`` 只包含 ``foo.h`` 就够了，不用再管后者所包含的其它内容。 +您所依赖的 symbols 被哪些头文件所定义，您就应该包含（include）哪些头文件，:ref:`forward-declaration` 情况除外。比如您要用到 ``bar.h`` 中的某个 symbol, 哪怕您所包含的 ``foo.h`` 已经包含了 ``bar.h``, 也照样得包含 ``bar.h``, 除非 ``foo.h`` 有明确说明它会自动向您提供 ``bar.h`` 中的 symbol. 不过，凡是 cc 文件所对应的「相关头文件」已经包含的，就不用再重复包含进其 cc 文件里面了，就像 ``foo.cc`` 只包含 ``foo.h`` 就够了，不用再管后者所包含的其它内容。 举例来说, ``google-awesome-project/src/foo/internal/fooserver.cc`` 的包含次序如下: .. code-block:: c++ - + #include "foo/public/fooserver.h" // 优先位置 #include @@ -154,13 +158,13 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 #include "base/basictypes.h" #include "base/commandlineflags.h" #include "foo/public/bar.h" - + 例外： 有时，平台特定（system-specific）代码需要条件编译（conditional includes），这些代码可以放到其它 includes 之后。当然，您的平台特定代码也要够简练且独立，比如： .. code-block:: c++ - + #include "foo/public/fooserver.h" #include "base/port.h" // For LANG_CXX11. @@ -170,7 +174,7 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 #endif // LANG_CXX11 译者 (YuleFox) 笔记 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ #. 避免多重包含是学编程时最基本的要求; #. 前置声明是为了降低编译依赖，防止修改一个头文件引发多米诺效应; @@ -179,9 +183,8 @@ C/C++ 函数参数分为输入参数, 输出参数, 和输入/输出参数三种 #. 标准化函数参数顺序可以提高可读性和易维护性 (对函数参数的堆栈空间有轻微影响, 我以前大多是相同类型放在一起); #. 包含文件的名称使用 ``.`` 和 ``..`` 虽然方便却易混乱, 使用比较完整的项目路径看上去很清晰, 很条理, 包含文件的次序除了美观之外, 最重要的是可以减少隐藏依赖, 使每个头文件在 "最需要编译" (对应源文件处 :D) 的地方编译, 有人提出库文件放在最后, 这样出错先是项目内的文件, 头文件都放在对应源文件的最前面, 这一点足以保证内部错误的及时发现了. - 译者（acgtyrant）笔记 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ #. 原来还真有项目用 ``#includes`` 来插入文本，且其文件扩展名 ``.inc`` 看上去也很科学。 #. Google 已经不再提倡 ``-inl.h`` 用法。 diff --git a/google-cpp-styleguide/magic.rst b/google-cpp-styleguide/magic.rst index bf9482c..7521b38 100644 --- a/google-cpp-styleguide/magic.rst +++ b/google-cpp-styleguide/magic.rst @@ -1,10 +1,10 @@ 4. 来自 Google 的奇技 ------------------------- +------------------- Google 用了很多自己实现的技巧 / 工具使 C++ 代码更加健壮, 我们使用 C++ 的方式可能和你在其它地方见到的有所不同. 4.1. 所有权与智能指针 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ .. tip:: 动态分配出的对象最好有单一且固定的所有主（onwer）, 且通过智能指针传递所有权（ownership）. @@ -12,7 +12,7 @@ Google 用了很多自己实现的技巧 / 工具使 C++ 代码更加健壮, 我 定义： 所有权是一种登记／管理动态内存和其它资源的技术。动态分配出的对象的所有主是一个对象或函数，后者负责确保当前者无用时就自动销毁前者。所有权有时可以共享，那么就由最后一个所有主来负责销毁它。甚至也可以不用共享，在代码中直接把所有权传递给其它对象。 - + 其实您可以把智能指针当成一个重载了 ``*`` 和 ``->`` 的「对象」来看。智能指针类型被用来自动化所有权的登记工作，来确保执行销毁义务到位。`std::unique_ptr `_ 是 C++11 新推出的一种智能指针类型，用来表示动态分配出的对象的「独一无二」所有权；当 ``std::unique_ptr`` 离开作用域，对象就会被销毁。不能复制 ``std::unique_ptr``, 但可以把它移动（move）给新所有主。`std::shared_ptr `_ 同样表示动态分配对象的所有权，但可以被共享，也可以被复制；对象的所有权由所有复制者共同拥有，最后一个复制者被销毁时，对象也会随着被销毁。 优点： @@ -37,18 +37,18 @@ Google 用了很多自己实现的技巧 / 工具使 C++ 代码更加健壮, 我 * 智能指针并不能够完全代替原生指针。 4.2. cpplint -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ .. tip:: 使用 ``cpplint.py`` 检查风格错误. - + ``cpplint.py`` 是一个用来分析源文件, 能检查出多种风格错误的工具. 它不并完美, 甚至还会漏报和误报, 但它仍然是一个非常有用的工具. 在行尾加 ``// NOLINT``, 或在上一行加 ``// NOLINTNEXTLINE``, 可以忽略报错。 某些项目会指导你如何使用他们的项目工具运行 ``cpplint.py``. 如果你参与的项目没有提供, 你可以单独下载 `cpplint.py `_. 译者（acgtyrant）笔记 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ #. 把智能指针当成对象来看待的话，就很好领会它与所指对象之间的关系了。 #. 原来 Rust 的 Ownership 思想是受到了 C++ 智能指针的很大启发啊。 diff --git a/google-cpp-styleguide/naming.rst b/google-cpp-styleguide/naming.rst index 1d27a57..1c8962b 100644 --- a/google-cpp-styleguide/naming.rst +++ b/google-cpp-styleguide/naming.rst @@ -1,79 +1,78 @@ 6. 命名约定 ------------- +--------- 最重要的一致性规则是命名管理. 命名风格快速获知名字代表是什么东东: 类型? 变量? 函数? 常量? 宏 ... ? 甚至不需要去查找类型声明. 我们大脑中的模式匹配引擎可以非常可靠的处理这些命名规则. 命名规则具有一定随意性, 但相比按个人喜好命名, 一致性更重, 所以不管你怎么想, 规则总归是规则. 6.1. 通用命名规则 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 函数命名，变量命名，文件命名要有描述性；少用缩写。 - + 尽可能给有描述性的命名，别心疼空间，毕竟让代码易于新读者理解很重要。不要用只有项目开发者能理解的缩写，也不要通过砍掉几个字母来缩写单词。 - + .. code-block:: c++ - + int price_count_reader; // 无缩写 int num_errors; // “num” 本来就很常见 int num_dns_connections; // 人人都知道 “DNS” 是啥 - + .. warning:: - + .. code-block:: c++ - + int n; // 莫名其妙。 int nerr; // 怪缩写。 int n_comp_conns; // 怪缩写。 int wgc_connections; // 只有贵团队知道是啥意思。 int pc_reader; // "pc" 有太多可能的解释了。 int cstmr_id; // 有删减若干字母。 - - + 6.2. 文件命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 文件名要全部小写, 可以包含下划线 (``_``) 或连字符 (``-``). 按项目约定来. 如果并没有项目约定，"_" 更好。 可接受的文件命名:: - + * my_useful_class.cc * my-useful-class.cc * myusefulclass.cc * muusefulclass_test.cc // ``_unittest`` 和 ``_regtest`` 已弃用。 - C++ 文件要以 ``.cc`` 结尾, 头文件以 ``.h`` 结尾. 专门插入文本的文件则以 ``.inc`` 结尾，参见 self-contained headers - + C++ 文件要以 ``.cc`` 结尾, 头文件以 ``.h`` 结尾. 专门插入文本的文件则以 ``.inc`` 结尾，参见:ref:`self-contained headers`。 + 不要使用已经存在于 ``/usr/include`` 下的文件名 (yospaly 注: 即编译器搜索系统头文件的路径), 如 ``db.h``. - + 通常应尽量让文件名更加明确. ``http_server_logs.h`` 就比 ``logs.h`` 要好. 定义类时文件名一般成对出现, 如 ``foo_bar.h`` 和 ``foo_bar.cc``, 对应于类 ``FooBar``. - + 内联函数必须放在 ``.h`` 文件中. 如果内联函数比较短, 就直接放在 ``.h`` 中. 6.3. 类型命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 类型名称的每个单词首字母均大写, 不包含下划线: ``MyExcitingClass``, ``MyExcitingEnum``. - + 所有类型命名 —— 类, 结构体, 类型定义 (``typedef``), 枚举 —— 均使用相同约定. 例如: .. code-block:: c++ - + // classes and structs class UrlTable { ... class UrlTableTester { ... struct UrlTableProperties { ... - + // typedefs typedef hash_map PropertiesMap; - + // enums enum UrlTableErrors { ... - + 6.4. 变量命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 变量名一律小写, 单词之间用下划线连接. 类的成员变量以下划线结尾, 但结构体的就不用，如:: ``a_local_variable``, ``a_struct_data_member``, ``a_class_data_member_``. @@ -81,21 +80,21 @@ 普通变量命名: 举例:: - + string table_name; // OK - uses underscore. string tablename; // OK - all lowercase. - + .. warning:: .. code-block:: c++ - + string tableName; // Bad - mixed case. 类数据成员： 不管是静态的还是非静态的，结构体数据成员都可以和普通变量一样, 但要接下划线。 - + .. code-block:: c++ - + class TableInfo { ... private: @@ -103,58 +102,57 @@ string tablename_; // OK. static Pool* pool_; // OK. }; - + 结构体变量: 不管是静态的还是非静态的，结构体数据成员都可以和普通变量一样, 不用像类那样接下划线: - + .. code-block:: c++ - + struct UrlTableProperties { string name; int num_entries; } - + 结构体与类的讨论参考 :ref:`结构体 vs. 类 ` 一节. - + 全局变量: 对全局变量没有特别要求, 少用就好, 但如果你要用, 可以用 ``g_`` 或其它标志作为前缀, 以便更好的区分局部变量. - .. _constant-names: 6.5. 常量命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 在全局或类里的常量名称前加 ``k``: kDaysInAWeek. 且除去开头的 ``k`` 之外每个单词开头字母均大写。 - + 所有编译时常量, 无论是局部的, 全局的还是类中的, 和其他变量稍微区别一下. ``k`` 后接大写字母开头的单词: .. code-block:: c++ const int kDaysInAWeek = 7; - + 这规则适用于编译时的局部作用域常量，不过要按变量规则来命名也可以。 .. _function-names: 6.6. 函数命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 常规函数使用大小写混合, 取值和设值函数则要求与变量名匹配: ``MyExcitingFunction()``, ``MyExcitingMethod()``, ``my_exciting_member_variable()``, ``set_my_exciting_member_variable()``. - + 常规函数: 函数名的每个单词首字母大写, 没有下划线。 - + 如果您的某函数出错时就要直接 crash, 那么就在函数名加上 OrDie. 但这函数本身必须集成在产品代码里，且平时也可能会出错。 - + .. code-block:: c++ - + AddTableEntry() DeleteUrl() OpenFileOrDie() @@ -162,9 +160,9 @@ 取值和设值函数: 取值（Accessors）和设值（Mutators）函数要与存取的变量名匹配. 这儿摘录一个类, ``num_entries_`` 是该类的实例变量: - + .. code-block:: c++ - + class MyClass { public: ... @@ -174,26 +172,26 @@ private: int num_entries_; }; - + 其它非常短小的内联函数名也可以用小写字母, 例如. 如果你在循环中调用这样的函数甚至都不用缓存其返回值, 小写命名就可以接受. - + 6.7. 名字空间命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 名字空间用小写字母命名, 并基于项目名称和目录结构: ``google_awesome_project``. - + 关于名字空间的讨论和如何命名, 参考 :ref:`名字空间 ` 一节. 6.8. 枚举命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 枚举的命名应当和 :ref:`常量 ` 或 :ref:`宏 ` 一致: ``kEnumName`` 或是 ``ENUM_NAME``. - + 单独的枚举值应该优先采用 :ref:`常量 ` 的命名方式. 但 :ref:`宏 ` 方式的命名也可以接受. 枚举名 ``UrlTableErrors`` (以及 ``AlternateUrlTableErrors``) 是类型, 所以要用大小写混合的方式. .. code-block:: c++ - + enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, @@ -210,35 +208,34 @@ .. _macro-names: 6.9. 宏命名 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~ .. tip:: - 你并不打算 :ref:`使用宏 `, 对吧? 如果你一定要用, 像这样命名: ``MY_MACRO_THAT_SCARES_SMALL_CHILDREN``. + 你并不打算:ref:`使用宏 `, 对吧? 如果你一定要用, 像这样命名: ``MY_MACRO_THAT_SCARES_SMALL_CHILDREN``. + +参考:ref:`预处理宏 `; 通常 *不应该* 使用宏. 如果不得不用, 其命名像枚举命名一样全部大写, 使用下划线:: -参考 `预处理宏 `; 通常 *不应该* 使用宏. 如果不得不用, 其命名像枚举命名一样全部大写, 使用下划线:: - #define ROUND(x) ... #define PI_ROUNDED 3.0 - 6.10. 命名规则的特例 -~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ .. tip:: 如果你命名的实体与已有 C/C++ 实体相似, 可参考现有命名策略. ``bigopen()``: 函数名, 参照 ``open()`` 的形式 - + ``uint``: ``typedef`` - + ``bigpos``: ``struct`` 或 ``class``, 参照 ``pos`` 的形式 - + ``sparse_hash_map``: STL 相似实体; 参照 STL 命名约定 - + ``LONGLONG_MAX``: 常量, 如同 ``INT_MAX`` diff --git a/google-cpp-styleguide/others.rst b/google-cpp-styleguide/others.rst index c074083..525923c 100644 --- a/google-cpp-styleguide/others.rst +++ b/google-cpp-styleguide/others.rst @@ -1,82 +1,79 @@ 5. 其他 C++ 特性 ------------------------- +-------------- 5.1. 引用参数 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 所有按引用传递的参数必须加上 ``const``. - + 定义: 在 C 语言中, 如果函数需要修改变量的值, 参数必须为指针, 如 ``int foo(int *pval)``. 在 C++ 中, 函数还可以声明引用参数: ``int foo(int &val)``. - + 优点: 定义引用参数防止出现 ``(*pval)++`` 这样丑陋的代码. 像拷贝构造函数这样的应用也是必需的. 而且更明确, 不接受 ``NULL`` 指针. - + 缺点: 容易引起误解, 因为引用在语法上是值变量却拥有指针的语义. - + 结论: 函数参数列表中, 所有引用参数都必须是 ``const``: .. code-block:: c++ - + void Foo(const string &in, string *out); - + 事实上这在 Google Code 是一个硬性约定: 输入参数是值参或 ``const`` 引用, 输出参数为指针. 输入参数可以是 ``const`` 指针, 但决不能是非 ``const`` 的引用参数，除非用于交换，比如 ``swap()``. - + 有时候，在输入形参中用 ``const T*`` 指针比 ``const T&`` 更明智。比如： - + * 您会传 null 指针。 * 函数要把指针或对地址的引用赋值给输入形参。 - + 总之大多时候输入形参往往是 ``const T&``. 若用 ``const T*`` 说明输入另有处理。所以若您要用 ``const T*``, 则应有理有据，否则会害得读者误解。 - 5.2. 右值引用 -~~~~~~~~~~~~~~~~~~~~~~~~~~ - +~~~~~~~~~~~ + TODO .. _function-overloading: - 5.3. 函数重载 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 若要用好函数重载，最好能让读者一看调用点（call site）就胸有成竹，不用花心思猜测调用的重载函数到底是哪一种。该规则适用于构造函数。 - + 定义: 你可以编写一个参数类型为 ``const string&`` 的函数, 然后用另一个参数类型为 ``const char*`` 的函数重载它: .. code-block:: c++ - + class MyClass { public: void Analyze(const string &text); void Analyze(const char *text, size_t textlen); }; - + 优点: 通过重载参数不同的同名函数, 令代码更加直观. 模板化代码需要重载, 同时为使用者带来便利. - + 缺点: 如果函数单单靠不同的参数类型而重载（acgtyrant 注：这意味着参数数量不变），读者就得十分熟悉 C++ 五花八门的匹配规则，以了解匹配过程具体到底如何。另外，当派生类只重载了某个函数的部分变体，继承语义容易令人困惑。 - + 结论: 如果您打算重载一个函数, 可以试试改在函数名里加上参数信息。例如，用 ``AppendString()`` 和 ``AppendInt()`` 等， 而不是一口气重载多个 ``Append()``. - 5.4. 缺省参数 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 我们不允许使用缺省函数参数，少数极端情况除外。尽可能改用函数重载。 @@ -84,32 +81,31 @@ 优点: 当您有依赖缺省参数的函数时，您也许偶尔会修改修改这些缺省参数。通过缺省参数，不用再为个别情况而特意定义一大堆函数了。与函数重载相比，缺省参数语法更为清晰，代码少，也很好地区分了「必选参数」和「可选参数」。 - + 缺点: 缺省参数会干扰函数指针，害得后者的函数签名（function signature）往往对不上所实际要调用的函数签名。即在一个现有函数添加缺省参数，就会改变它的类型，那么调用其地址的代码可能会出错，不过函数重载就没这问题了。此外，缺省参数会造成臃肿的代码，毕竟它们在每一个调用点（call site）都有重复（acgtyrant 注：我猜可能是因为调用函数的代码表面上看来省去了不少参数，但编译器在编译时还是会在每一个调用代码里统统补上所有默认实参信息，造成大量的重复）。函数重载正好相反，毕竟它们所谓的「缺省参数」只会出现在函数定义里。 - + 结论: 由于缺点并不是很严重，有些人依旧偏爱缺省参数胜于函数重载。所以除了以下情况，我们要求必须显式提供所有参数（acgtyrant 注：即不能再通过缺省参数来省略参数了）。 - + 其一，位于 ``.cc`` 文件里的静态函数或匿名空间函数，毕竟都只能在局部文件里调用该函数了。 - + 其二，可以在构造函数里用缺省参数，毕竟不可能取得它们的地址。 - + 其三，可以用来模拟变长数组。 - + .. code-block:: c++ - + // 通过空 AlphaNum 以支持四个形参 string StrCat(const AlphaNum &a, const AlphaNum &b = gEmptyAlphaNum, const AlphaNum &c = gEmptyAlphaNum, const AlphaNum &d = gEmptyAlphaNum); - 5.5. 变长数组和 alloca() -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ .. tip:: 我们不允许使用变长数组和 ``alloca()``. @@ -121,25 +117,23 @@ 缺点: 变长数组和 ``alloca()`` 不是标准 C++ 的组成部分. 更重要的是, 它们根据数据大小动态分配堆栈内存, 会引起难以发现的内存越界 bugs: "在我的机器上运行的好好的, 发布后却莫名其妙的挂掉了". - + 结论: 改用更安全的分配器（allocator），就像 ``std::vector`` 或 ``std::unique_ptr``. - 5.6. 友元 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~ .. tip:: 我们允许合理的使用友元类及友元函数. - + 通常友元应该定义在同一文件内, 避免代码读者跑到其它文件查找使用该私有成员的类. 经常用到友元的一个地方是将 ``FooBuilder`` 声明为 ``Foo`` 的友元, 以便 ``FooBuilder`` 正确构造 ``Foo`` 的内部状态, 而无需将该状态暴露出来. 某些情况下, 将一个单元测试类声明成待测类的友元会很方便. 友元扩大了 (但没有打破) 类的封装边界. 某些情况下, 相对于将类成员声明为 ``public``, 使用友元是更好的选择, 尤其是如果你只允许另一个类访问该类的私有成员时. 当然, 大多数类都只应该通过其提供的公有成员进行互操作. - 5.7. 异常 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~ .. tip:: 我们不使用 C++ 异常. @@ -153,108 +147,108 @@ - 有些第三方 C++ 库依赖异常，禁用异常就不好用了。 - 异常是处理构造函数失败的唯一途径。虽然可以用工厂函数（acgtyrant 注：factory function, 出自 C++ 的一种设计模式，即「简单工厂模式」）或 ``Init()`` 方法代替异常, but these require heap allocation or a new "invalid" state, respectively. - + - 在测试框架里很好用。 - + 缺点: - 在现有函数中添加 ``throw`` 语句时，您必须检查所有调用点。要么让所有调用点统统具备最低限度的异常安全保证，要么眼睁睁地看异常一路欢快地往上跑，最终中断掉整个程序。举例，``f()`` 调用 ``g()``, ``g()`` 又调用 ``h()``, 且 ``h`` 抛出的异常被 ``f`` 捕获。当心 ``g``, 否则会没妥善清理好。 - + - 还有更常见的，异常会彻底扰乱程序的执行流程并难以判断，函数也许会在您意料不到的地方返回。您或许会加一大堆何时何处处理异常的规定来降低风险，然而开发者的记忆负担更重了。 - + - Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it. - 启用异常会增加二进制文件数据，延长编译时间（或许影响小），还可能加大地址空间的压力。 - + - 滥用异常会变相鼓励开发者去捕捉不合时宜，或本来就已经没法恢复的「伪异常」。比如，用户的输入不符合格式要求时，也用不着抛异常。如此之类的伪异常列都列不完。 结论: 从表面上看来，使用异常利大于弊, 尤其是在新项目中. 但是对于现有代码, 引入异常会牵连到所有相关代码. 如果新项目允许异常向外扩散, 在跟以前未使用异常的代码整合时也将是个麻烦. 因为 Google 现有的大多数 C++ 代码都没有异常处理, 引入带有异常处理的新代码相当困难. - + 鉴于 Google 现有代码不接受异常, 在现有代码中使用异常比在新项目中使用的代价多少要大一些. 迁移过程比较慢, 也容易出错. 我们不相信异常的使用有效替代方案, 如错误代码, 断言等会造成严重负担. - + 我们并不是基于哲学或道德层面反对使用异常, 而是在实践的基础上. 我们希望在 Google 使用我们自己的开源项目, 但项目中使用异常会为此带来不便, 因此我们也建议不要在 Google 的开源项目中使用异常. 如果我们需要把这些项目推倒重来显然不太现实. - + 对于 Windows 代码来说, 有个 :ref:`特例 `. (YuleFox 注: 对于异常处理, 显然不是短短几句话能够说清楚的, 以构造函数为例, 很多 C++ 书籍上都提到当构造失败时只有异常可以处理, Google 禁止使用异常这一点, 仅仅是为了自身的方便, 说大了, 无非是基于软件管理成本上, 实际使用中还是自己决定) +.. _RTTI: 5.8. 运行时类型识别 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ + TODO .. tip:: 我们禁止使用 RTTI. - + 定义: RTTI 允许程序员在运行时识别 C++ 类对象的类型. - + 优点: RTTI 在某些单元测试中非常有用. 比如进行工厂类测试时, 用来验证一个新建对象是否为期望的动态类型. - + 除测试外, 极少用到. - + 缺点: 在运行时判断类型通常意味着设计问题. 如果你需要在运行期间确定一个对象的类型, 这通常说明你需要考虑重新设计你的类. - + 结论: 除单元测试外, 不要使用 RTTI. 如果你发现自己不得不写一些行为逻辑取决于对象类型的代码, 考虑换一种方式判断对象类型. - + 如果要实现根据子类类型来确定执行不同逻辑代码, 虚函数无疑更合适. 在对象内部就可以处理类型识别问题. - + 如果要在对象外部的代码中判断类型, 考虑使用双重分派方案, 如访问者模式. 可以方便的在对象本身之外确定类的类型. - + 如果你认为上面的方法你真的掌握不了, 你可以使用 RTTI, 但务必请三思 :-) . 不要试图手工实现一个貌似 RTTI 的替代方案, 我们反对使用 RTTI 的理由, 同样适用于那些在类型继承体系上使用类型标签的替代方案. - 5.9. 类型转换 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 使用 C++ 的类型转换, 如 ``static_cast<>()``. 不要使用 ``int y = (int)x`` 或 ``int y = int(x)`` 等转换方式; - + 定义: C++ 采用了有别于 C 的类型转换机制, 对转换操作进行归类. - + 优点: C 语言的类型转换问题在于模棱两可的操作; 有时是在做强制转换 (如 ``(int)3.5``), 有时是在做类型转换 (如 ``(int)"hello"``). 另外, C++ 的类型转换在查找时更醒目. - + 缺点: 恶心的语法. - + 结论: 不要使用 C 风格类型转换. 而应该使用 C++ 风格. - + - 用 ``static_cast`` 替代 C 风格的值转换, 或某个类指针需要明确的向上转换为父类指针时. - 用 ``const_cast`` 去掉 ``const`` 限定符. - 用 ``reinterpret_cast`` 指针类型和整型或其它指针之间进行不安全的相互转换. 仅在你对所做一切了然于心时使用. - 至于 ``dynamic_cast`` 参见 RTTI 章节。 - + 至于 ``dynamic_cast`` 参见 :ref:`RTTI`. 5.10. 流 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~ .. tip:: 只在记录日志时使用流. - + 定义: 流用来替代 ``printf()`` 和 ``scanf()``. - + 优点: 有了流, 在打印时不需要关心对象的类型. 不用担心格式化字符串与参数列表不匹配 (虽然在 gcc 中使用 ``printf`` 也不存在这个问题). 流的构造和析构函数会自动打开和关闭对应的文件. - + 缺点: 流使得 ``pread()`` 等功能函数很难执行. 如果不使用 ``printf`` 风格的格式化字符串, 某些格式化操作 (尤其是常用的格式字符串 ``%.*s``) 用流处理性能是很低的. 流不支持字符串操作符重新排序 (%1s), 而这一点对于软件国际化很有用. @@ -262,100 +256,97 @@ 结论: 不要使用流, 除非是日志接口需要. 使用 ``printf`` 之类的代替. - + 使用流还有很多利弊, 但代码一致性胜过一切. 不要在代码中使用流. 拓展讨论: 对这一条规则存在一些争论, 这儿给出点深层次原因. 回想一下唯一性原则 (Only One Way): 我们希望在任何时候都只使用一种确定的 I/O 类型, 使代码在所有 I/O 处都保持一致. 因此, 我们不希望用户来决定是使用流还是 ``printf + read/write``. 相反, 我们应该决定到底用哪一种方式. 把日志作为特例是因为日志是一个非常独特的应用, 还有一些是历史原因. - + 流的支持者们主张流是不二之选, 但观点并不是那么清晰有力. 他们指出的流的每个优势也都是其劣势. 流最大的优势是在输出时不需要关心打印对象的类型. 这是一个亮点. 同时, 也是一个不足: 你很容易用错类型, 而编译器不会报警. 使用流时容易造成的这类错误: .. code-block:: c++ - + cout << this; // Prints the address cout << *this; // Prints the contents - + 由于 ``<<`` 被重载, 编译器不会报错. 就因为这一点我们反对使用操作符重载. - + 有人说 ``printf`` 的格式化丑陋不堪, 易读性差, 但流也好不到哪儿去. 看看下面两段代码吧, 实现相同的功能, 哪个更清晰? .. code-block:: c++ - + cerr << "Error connecting to '" << foo->bar()->hostname.first << ":" << foo->bar()->hostname.second << ": " << strerror(errno); - + fprintf(stderr, "Error connecting to '%s:%u: %s", foo->bar()->hostname.first, foo->bar()->hostname.second, strerror(errno)); - + 你可能会说, "把流封装一下就会比较好了", 这儿可以, 其他地方呢? 而且不要忘了, 我们的目标是使语言更紧凑, 而不是添加一些别人需要学习的新装备. - + 每一种方式都是各有利弊, "没有最好, 只有更适合". 简单性原则告诫我们必须从中选择其一, 最后大多数决定采用 ``printf + read/write``. - 5.11. 前置自增和自减 -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ .. tip:: 对于迭代器和其他模板对象使用前缀形式 (``++i``) 的自增, 自减运算符. - + 定义: 对于变量在自增 (``++i`` 或 ``i++``) 或自减 (``--i`` 或 ``i--``) 后表达式的值又没有没用到的情况下, 需要确定到底是使用前置还是后置的自增 (自减). - + 优点: 不考虑返回值的话, 前置自增 (``++i``) 通常要比后置自增 (``i++``) 效率更高. 因为后置自增 (或自减) 需要对表达式的值 ``i`` 进行一次拷贝. 如果 ``i`` 是迭代器或其他非数值类型, 拷贝的代价是比较大的. 既然两种自增方式实现的功能一样, 为什么不总是使用前置自增呢? - + 缺点: 在 C 开发中, 当表达式的值未被使用时, 传统的做法是使用后置自增, 特别是在 ``for`` 循环中. 有些人觉得后置自增更加易懂, 因为这很像自然语言, 主语 (``i``) 在谓语动词 (``++``) 前. - + 结论: 对简单数值 (非对象), 两种都无所谓. 对迭代器和模板类型, 使用前置自增 (自减). - 5.12. ``const`` 用法 -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ .. tip:: 我们强烈建议你在任何可能的情况下都要使用 ``const``. 此外有时改用 C++11 推出的 constexpr 更好。 - + 定义: 在声明的变量或参数前加上关键字 ``const`` 用于指明变量值不可被篡改 (如 ``const int foo`` ). 为类中的函数加上 ``const`` 限定符表明该函数不会修改类成员变量的状态 (如 ``class Foo { int Bar(char c) const; };``). - + 优点: 大家更容易理解如何使用变量. 编译器可以更好地进行类型检测, 相应地, 也能生成更好的代码. 人们对编写正确的代码更加自信, 因为他们知道所调用的函数被限定了能或不能修改变量值. 即使是在无锁的多线程编程中, 人们也知道什么样的函数是安全的. - + 缺点: ``const`` 是入侵性的: 如果你向一个函数传入 ``const`` 变量, 函数原型声明中也必须对应 ``const`` 参数 (否则变量需要 ``const_cast`` 类型转换), 在调用库函数时显得尤其麻烦. - + 结论: ``const`` 变量, 数据成员, 函数和参数为编译时类型检测增加了一层保障; 便于尽早发现错误. 因此, 我们强烈建议在任何可能的情况下使用 ``const``: - + - 如果函数不会修改传你入的引用或指针类型参数, 该参数应声明为 ``const``. - 尽可能将函数声明为 ``const``. 访问函数应该总是 ``const``. 其他不会修改任何数据成员, 未调用非 ``const`` 函数, 不会返回数据成员非 ``const`` 指针或引用的函数也应该声明成 ``const``. - 如果数据成员在对象构造之后不再发生变化, 可将其定义为 ``const``. - + 然而, 也不要发了疯似的使用 ``const``. 像 ``const int * const * const x;`` 就有些过了, 虽然它非常精确的描述了常量 ``x``. 关注真正有帮助意义的信息: 前面的例子写成 ``const int** x`` 就够了. - + 关键字 ``mutable`` 可以使用, 但是在多线程中是不安全的, 使用时首先要考虑线程安全. ``const`` 的位置: 有人喜欢 ``int const *foo`` 形式, 不喜欢 ``const int* foo``, 他们认为前者更一致因此可读性也更好: 遵循了 ``const`` 总位于其描述的对象之后的原则. 但是一致性原则不适用于此, "不要过度使用" 的声明可以取消大部分你原本想保持的一致性. 将 ``const`` 放在前面才更易读, 因为在自然语言中形容词 (``const``) 是在名词 (``int``) 之前. - + 这是说, 我们提倡但不强制 ``const`` 在前. 但要保持代码的一致性! (yospaly 注: 也就是不要在一些地方把 ``const`` 写在类型前面, 在其他地方又写在后面, 确定一种写法, 然后保持一致.) - 5.13. ``constexpr`` 用法 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~ .. tip:: 在 C++11 里，用 constexpr 来定义真正的常量，或实现常量初始化。 @@ -376,69 +367,67 @@ 靠 constexpr 特性，方才实现了 C++ 在接口上打造真正常量机制的可能。好好用 constexpr 来定义真・常量以及支持常量的函数。Avoid complexifying function definitions to enable their use with constexpr. 千万别痴心妄想地想靠 constexpr 来强制代码「内联」。 - 5.14. 整型 -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~ .. tip:: C++ 内建整型中, 仅使用 ``int``. 如果程序中需要不同大小的变量, 可以使用 ```` 中长度精确的整型, 如 ``int16_t``.如果您的变量可能不小于 2^31 (2GiB), 就用 64 位变量比如 ``int64_t``. 此外要留意，哪怕您的值并不会超出 int 所能够表示的范围，在计算过程中也可能会溢出。所以拿不准时，干脆用更大的类型。 - + 定义: C++ 没有指定整型的大小. 通常人们假定 ``short`` 是 16 位, ``int``是 32 位, ``long`` 是 32 位, ``long long`` 是 64 位. - + 优点: 保持声明统一. - + 缺点: C++ 中整型大小因编译器和体系结构的不同而不同. - + 结论: ```` 定义了 ``int16_t``, ``uint32_t``, ``int64_t`` 等整型, 在需要确保整型大小时可以使用它们代替 ``short``, ``unsigned long long`` 等. 在 C 整型中, 只使用 ``int``. 在合适的情况下, 推荐使用标准类型如 ``size_t`` 和 ``ptrdiff_t``. - + 如果已知整数不会太大, 我们常常会使用 ``int``, 如循环计数. 在类似的情况下使用原生类型 ``int``. 你可以认为 ``int`` 至少为 32 位, 但不要认为它会多于 ``32`` 位. 如果需要 64 位整型, 用 ``int64_t`` 或 ``uint64_t``. - + 对于大整数, 使用 ``int64_t``. - + 不要使用 ``uint32_t`` 等无符号整型, 除非你是在表示一个位组而不是一个数值, 或是你需要定义二进制补码溢出. 尤其是不要为了指出数值永不会为负, 而使用无符号类型. 相反, 你应该使用断言来保护数据. - + 如果您的代码涉及容器返回的大小（size），确保其类型足以应付容器各种可能的用法。拿不准时，类型越大越好。 小心整型类型转换和整型提升（acgtyrant 注：integer promotions, 比如 ``int`` 与 ``unsigned int`` 运算时，前者被提升为 ``unsigned int`` 而有可能溢出），总有意想不到的后果。 - + 关于无符号整数: 有些人, 包括一些教科书作者, 推荐使用无符号类型表示非负数. 这种做法试图达到自我文档化. 但是, 在 C 语言中, 这一优点被由其导致的 bug 所淹没. 看看下面的例子: .. code-block:: c++ - + for (unsigned int i = foo.Length()-1; i >= 0; --i) ... - + 上述循环永远不会退出! 有时 gcc 会发现该 bug 并报警, 但大部分情况下都不会. 类似的 bug 还会出现在比较有符合变量和无符号变量时. 主要是 C 的类型提升机制会致使无符号类型的行为出乎你的意料. - + 因此, 使用断言来指出变量为非负数, 而不是使用无符号型! - 5.15. 64 位下的可移植性 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~ .. tip:: 代码应该对 64 位和 32 位系统友好. 处理打印, 比较, 结构体对齐时应切记: - + - 对于某些类型, ``printf()`` 的指示符在 32 位和 64 位系统上可移植性不是很好. C99 标准定义了一些可移植的格式化指示符. 不幸的是, MSVC 7.1 并非全部支持, 而且标准中也有所遗漏, 所以有时我们不得不自己定义一个丑陋的版本 (头文件 ``inttypes.h`` 仿标准风格): - + .. code-block:: c++ - + // printf macros for size_t, in the style of inttypes.h #ifdef _LP64 #define __PRIS_PREFIX "z" #else #define __PRIS_PREFIX #endif - + // Use these macros after a % in a printf format string // to get correct 32/64 bit behavior, like this: // size_t size = records.size(); @@ -448,8 +437,8 @@ #define PRIuS __PRIS_PREFIX "u" #define PRIXS __PRIS_PREFIX "X" #define PRIoS __PRIS_PREFIX "o" - - + + +-------------------+---------------------+--------------------------+------------------+ | 类型 | 不要使用 | 使用 | 备注 | +===================+=====================+==========================+==================+ @@ -466,30 +455,29 @@ +-------------------+---------------------+--------------------------+------------------+ 注意 ``PRI*`` 宏会被编译器扩展为独立字符串. 因此如果使用非常量的格式化字符串, 需要将宏的值而不是宏名插入格式中. 使用 ``PRI*`` 宏同样可以在 ``%`` 后包含长度指示符. 例如, ``printf("x = %30"PRIuS"\n", x)`` 在 32 位 Linux 上将被展开为 ``printf("x = %30" "u" "\n", x)``, 编译器当成 ``printf("x = %30u\n", x)`` 处理 (yospaly 注: 这在 MSVC 6.0 上行不通, VC 6 编译器不会自动把引号间隔的多个字符串连接一个长字符串). - + - 记住 ``sizeof(void *) != sizeof(int)``. 如果需要一个指针大小的整数要用 ``intptr_t``. - 你要非常小心的对待结构体对齐, 尤其是要持久化到磁盘上的结构体 (yospaly 注: 持久化 - 将数据按字节流顺序保存在磁盘文件或数据库中). 在 64 位系统中, 任何含有 ``int64_t``/``uint64_t`` 成员的类/结构体, 缺省都以 8 字节在结尾对齐. 如果 32 位和 64 位代码要共用持久化的结构体, 需要确保两种体系结构下的结构体对齐一致. 大多数编译器都允许调整结构体对齐. gcc 中可使用 ``__attribute__((packed))``. MSVC 则提供了 ``#pragma pack()`` 和 ``__declspec(align())`` (YuleFox 注, 解决方案的项目属性里也可以直接设置). - + - 创建 64 位常量时使用 LL 或 ULL 作为后缀, 如: .. code-block:: c++ - + int64_t my_value = 0×123456789LL; uint64_t my_mask = 3ULL << 48; - - -- 如果你确实需要 32 位和 64 位系统具有不同代码, 可以使用 ``#ifdef _LP64`` 指令来切分 32/64 位代码. (尽量不要这么做, 如果非用不可, 尽量使修改局部化) +- 如果你确实需要 32 位和 64 位系统具有不同代码, 可以使用 ``#ifdef _LP64`` 指令来切分 32/64 位代码. (尽量不要这么做, 如果非用不可, 尽量使修改局部化) + .. _preprocessor-macros: 5.16. 预处理宏 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ .. tip:: 使用宏时要非常谨慎, 尽量以内联函数, 枚举和常量代替之. - + 宏意味着你和编译器看到的代码是不同的. 这可能会导致异常行为, 尤其因为宏具有全局作用域. 值得庆幸的是, C++ 中, 宏不像在 C 中那么必不可少. 以往用宏展开性能关键的代码, 现在可以用内联函数替代. 用宏表示常量可被 ``const`` 变量代替. 用宏 "缩写" 长变量名可被引用代替. 用宏进行条件编译... 这个, 千万别这么做, 会令测试更加痛苦 (``#define`` 防止头文件重包含当然是个特例). @@ -497,65 +485,62 @@ 宏可以做一些其他技术无法实现的事情, 在一些代码库 (尤其是底层库中) 可以看到宏的某些特性 (如用 ``#`` 字符串化, 用 ``##`` 连接等等). 但在使用前, 仔细考虑一下能不能不使用宏达到同样的目的. 下面给出的用法模式可以避免使用宏带来的问题; 如果你要宏, 尽可能遵守: - + - 不要在 ``.h`` 文件中定义宏. - 在马上要使用时才进行 ``#define``, 使用后要立即 ``#undef``. - 不要只是对已经存在的宏使用#undef，选择一个不会冲突的名称； - 不要试图使用展开后会导致 C++ 构造不稳定的宏, 不然也至少要附上文档说明其行为. - 不要用 ``##`` 处理函数，类和变量的名字。 - 5.17. 0, ``nullptr`` 和 ``NULL`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. tip:: 整数用 ``0``, 实数用 ``0.0``, 指针用 ``nullptr`` 或 ``NULL``, 字符 (串) 用 ``'\0'``. - + 整数用 ``0``, 实数用 ``0.0``, 这一点是毫无争议的. - + 对于指针 (地址值), 到底是用 ``0``, ``NULL`` 还是 ``nullptr``. C++11 项目用 ``nullptr``; C++03 项目则用 ``NULL``, 毕竟它看起来像指针。实际上，一些 C++ 编译器对 ``NULL`` 的定义比较特殊，可以输出有用的警告，特别是 ``sizeof(NULL)`` 就和 ``sizeof(0)`` 不一样。 - + 字符 (串) 用 ``'\0'``, 不仅类型正确而且可读性好. - 5.18. sizeof -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ .. tip:: 尽可能用 ``sizeof(varname)`` 代替 ``sizeof(type)``. - + 使用 ``sizeof(varname)`` 是因为当代码中变量类型改变时会自动更新. 您或许会用 ``sizeof(type)`` 处理不涉及任何变量的代码，比如处理来自外部或内部的数据格式，这时用变量就不合适了。 .. code-block:: c++ - + Struct data; Struct data; memset(&data, 0, sizeof(data)); - + .. warning:: .. code-block:: c++ - + memset(&data, 0, sizeof(Struct)); - + .. code-block:: c++ - + if (raw_size < sizeof(int)) { LOG(ERROR) << "compressed record not big enough for count: " << raw_size; return false; } - 5.19. auto -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~ .. tip:: 用 ``auto`` 绕过烦琐的类型名，只要可读性好就继续用，别用在局部变量之外的地方。 - + 定义： C++11 中，若变量被声明成 ``auto``, 那它的类型就会被自动匹配成初始化表达式的类型。您可以用 ``auto`` 来复制初始化或绑定引用。 - + .. code-block:: c++ - + vector v; ... auto s1 = v[0]; // Makes a copy of v[0]. @@ -564,92 +549,94 @@ 优点： C++ 类型名有时又长又臭，特别是涉及模板或命名空间的时候。就像： - + .. code-block:: c++ - + sparse_hash_map::iterator iter = m.find(val); - + 返回类型好难读，代码目的也不够一目了然。重构其： - + .. code-block:: c++ - + auto iter = m.find(val); - + 好多了。 - + 没有 ``auto`` 的话，我们不得不在同一个表达式里写同一个类型名两次，无谓的重复，就像： - + .. code-block:: c++ - + diagnostics::ErrorStatus* status = new diagnostics::ErrorStatus("xyz"); - + 有了 auto, 可以更方便地用中间变量，显式编写它们的类型轻松点。 - + 缺点： 类型够明显时，特别是初始化变量时，代码才会够一目了然。但以下就不一样了： - + .. code-block:: c++ - + auto i = x.Lookup(key); - + 看不出其类型是啥，x 的类型声明恐怕远在几百行之外了。 - + 程序员必须会区分 ``auto`` 和 ``const auto&`` 的不同之处，否则会复制错东西。 - + auto 和 C++11 列表初始化的合体令人摸不着头脑： - + .. code-block:: c++ - + auto x(3); // Note: parentheses. auto y{3}; // Note: curly braces. - + 它们不是同一回事——``x`` 是 ``int``, ``y`` 则是 ``std::initializer_list``. 其它一般不可见的代理类型（acgtyrant 注：normally-invisible proxy types, 它涉及到 C++ 鲜为人知的坑：`Why is vector not a STL container? `_）也有大同小异的陷阱。 - + 如果在接口里用 ``auto``, 比如声明头文件里的一个常量，那么只要仅仅因为程序员一时修改其值而导致类型变化的话——API 要翻天覆地了。 -决定： +结论： ``auto`` 只能用在局部变量里用。别用在文件作用域变量，命名空间作用域变量和类数据成员里。永远别列表初始化 ``auto`` 变量。 ``auto`` 还可以和 C++11 特性「尾置返回类型（trailing return type）」一起用，不过后者只能用在 lambda 表达式里。 +.. _braced_initializer_list: + 5.20. 列表初始化 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 你可以用列表初始化。 - + 早在 C++03 里，聚合类型（aggregate types）就已经可以被列表初始化了，比如数组和不自带构造函数的结构体： - + .. code-block:: c++ - + struct Point { int x; int y; }; Point p = {1, 2}; - + C++11 中，该特性得到进一步的推广，任何对象类型都可以被列表初始化。示范如下： - + .. code-block:: c++ // Vector takes a braced-init-list of elements. vector v{"foo", "bar"}; - + // Basically the same, ignoring some small technicalities. // You may choose to use either form. vector v = {"foo", "bar"}; - + // Usable with 'new' expressions. auto p = new vector{"foo", "bar"}; - + // A map can take a list of pairs. Nested braced-init-lists work. map m = {{1, "one"}, {2, "2"}}; - + // A braced-init-list can be implicitly converted to a return type. vector test_function() { return {1, 2, 3}; } - + // Iterate over a braced-init-list. for (int i : {-1, -2, -3}) {} - + // Call a function using a braced-init-list. void TestFunction2(vector v) {} TestFunction2({1, 2, 3}); @@ -671,11 +658,11 @@ } }; MyType m{2, 3, 5, 7}; - + 最后，列表初始化也适用于常规数据类型的构造，哪怕没有接收 ``std::initializer_list`` 的构造函数。 - + .. code-block:: c++ - + double d{1.23}; // Calls ordinary constructor as long as MyOtherType has no // std::initializer_list constructor. @@ -687,39 +674,38 @@ MyOtherType m = {1, "b"}; // If the constructor is explicit, you can't use the "= {}" form. MyOtherType m{"b"}; - + 千万别直接列表初始化 auto 变量，看下一句，估计没人看得懂： .. warning:: .. code-block:: c++ - - auto d = {1.23}; // d is a std::initializer_list - - .. code-block:: c++ - - auto d = double{1.23}; // Good -- d is a double, not a std::initializer_list. - - 至于格式化，参见 Braced_Initializer_List_Format. + auto d = {1.23}; // d is a std::initializer_list + + .. code-block:: c++ + + auto d = double{1.23}; // Good -- d is a double, not a std::initializer_list. + + 至于格式化，参见 :ref:`braced-initializer-list-format`. 5.21. Lambda 表达式 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~ .. tip:: 适当使用 lambda 表达式。别用默认 lambda 捕获，所有捕获都要显式写出来。 - + 定义： Lambda 表达式是创建匿名函数对象的一种简易途径，常用于把函数当参数传，例如： - + .. code-block:: c++ - + std::sort(v.begin(), v.end(), [](int x, int y) { return Weight(x) < Weight(y); }); - + C++11 首次提出 Lambdas, 还提供了一系列处理函数对象的工具，比如多态包装器（polymorphic wrapper） ``std::function``. - + 优点： * 传函数对象给 STL 算法，Lambdas 最简易，可读性也好。 @@ -738,11 +724,13 @@ * 如果可读性更好，就显式写出 lambd 的尾置返回类型，就像auto. 5.22. 模板元编程 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ + TODO +.. _boost: 5.23. Boost 库 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ .. tip:: 只使用 Boost 中被认可的库. @@ -750,55 +738,54 @@ 定义: `Boost 库集 `_ 是一个广受欢迎, 经过同行鉴定, 免费开源的 C++ 库集. - + 优点: Boost代码质量普遍较高, 可移植性好, 填补了 C++ 标准库很多空白, 如型别的特性, 更完善的绑定器, 更好的智能指针。 - + 缺点: 某些 Boost 库提倡的编程实践可读性差, 比如元编程和其他高级模板技术, 以及过度 "函数化" 的编程风格. - + 结论: 为了向阅读和维护代码的人员提供更好的可读性, 我们只允许使用 Boost 一部分经认可的特性子集. 目前允许使用以下库: - - - `Call Traits `_ : ``boost/call_traits.hpp`` - - - `Compressed Pair `_ : ``boost/compressed_pair.hpp`` - - - ``_ : ``boost/graph``, except serialization (``adj_list_serialize.hpp``) and parallel/distributed algorithms and data structures(``boost/graph/parallel/*`` and ``boost/graph/distributed/*``) - - - `Property Map `_ : ``boost/property_map.hpp`` - - - The part of `Iterator `_ that deals with defining iterators: ``boost/iterator/iterator_adaptor.hpp``, ``boost/iterator/iterator_facade.hpp``, and ``boost/function_output_iterator.hpp`` - - - The part of `Polygon `_ that deals with Voronoi diagram construction and doesn't depend on the rest of Polygon: ``boost/polygon/voronoi_builder.hpp``, ``boost/polygon/voronoi_diagram.hpp``, and ``boost/polygon/voronoi_geometry_type.hpp`` - - - `Bimap `_ : ``boost/bimap`` - - - `Statistical Distributions and Functions `_ : ``boost/math/distributions`` - - - `Multi-index `_ : ``boost/multi_index`` - - - `Heap `_ : ``boost/heap`` - - - The flat containers from `Container `_: ``boost/container/flat_map``, and ``boost/container/flat_set`` - - 我们正在积极考虑增加其它 Boost 特性, 所以列表中的规则将不断变化. - - 以下库可以用，但由于如今已经被 C++ 11 标准库取代，不再鼓励： - - - `Pointer Container `_ : ``boost/ptr_container``, 改用 `std::array `_ - - - `Array `_ : ``boost/array.hpp``, 改用 `std::unique_ptr `_ + - `Call Traits `_ : ``boost/call_traits.hpp`` + + - `Compressed Pair `_ : ``boost/compressed_pair.hpp`` + + - ``_ : ``boost/graph``, except serialization (``adj_list_serialize.hpp``) and parallel/distributed algorithms and data structures(``boost/graph/parallel/*`` and ``boost/graph/distributed/*``) + + - `Property Map `_ : ``boost/property_map.hpp`` + + - The part of `Iterator `_ that deals with defining iterators: ``boost/iterator/iterator_adaptor.hpp``, ``boost/iterator/iterator_facade.hpp``, and ``boost/function_output_iterator.hpp`` + + - The part of `Polygon `_ that deals with Voronoi diagram construction and doesn't depend on the rest of Polygon: ``boost/polygon/voronoi_builder.hpp``, ``boost/polygon/voronoi_diagram.hpp``, and ``boost/polygon/voronoi_geometry_type.hpp`` + + - `Bimap `_ : ``boost/bimap`` + + - `Statistical Distributions and Functions `_ : ``boost/math/distributions`` + + - `Multi-index `_ : ``boost/multi_index`` + + - `Heap `_ : ``boost/heap`` + + - The flat containers from `Container `_: ``boost/container/flat_map``, and ``boost/container/flat_set`` + + 我们正在积极考虑增加其它 Boost 特性, 所以列表中的规则将不断变化. + + 以下库可以用，但由于如今已经被 C++ 11 标准库取代，不再鼓励： + + - `Pointer Container `_ : ``boost/ptr_container``, 改用 `std::array `_ + + - `Array `_ : ``boost/array.hpp``, 改用 `std::unique_ptr `_ 5.24. C++11 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: - 适当用 C++11（前身是 C++0x）的库和语言扩展，在贵项目用 C++11 特性前三思下可移植性。 + 适当用 C++11（前身是 C++0x）的库和语言扩展，在贵项目用 C++11 特性前三思可移植性。 定义： @@ -807,13 +794,13 @@ 优点： 在二〇一四年八月之前，C++11 一度是官方标准，被大多 C++ 编译器支持。它标准化很多我们早先就在用的 C++ 扩展，简化了不少操作，大大改善了性能和安全。 - + 缺点： C++11 相对于前身，复杂极了：1300 页 vs 800 页！很多开发者也不怎么熟悉它。于是从长远来看，前者特性对代码可读性以及维护代价难以预估。我们说不准什么时候采纳其特性，特别是在被迫依赖老实工具的项目上。 - - 和 Boost 一样，有些 C++11 扩展提倡实则对可读性有害的编程实践——就像去除冗余检查（比如类型名）以帮助读者，或是鼓励模板原编程等等。有些扩展在功能上与原有机制冲突，容易招致困惑以及迁移代价。 - + + 和 :ref:`boost` 一样，有些 C++11 扩展提倡实则对可读性有害的编程实践——就像去除冗余检查（比如类型名）以帮助读者，或是鼓励模板原编程等等。有些扩展在功能上与原有机制冲突，容易招致困惑以及迁移代价。 + 缺点： C++11 特性除了个别情况下，可以用一用。除了本指南会有不少章节会加以讨若干 C++11 特性之外，以下特性最好不要用： @@ -823,15 +810,14 @@ - ```` 和 ``` 头文件，因为编译器尚不支持。 - 默认 lambda 捕获。 +译者（acgtyrant）笔记 +~~~~~~~~~~~~~~~~~~~ -译者 acgtyrant 笔记： -~~~~~~~~~~~~~~~~~~~~~~~~~~ - - #. 实际上，`缺省参数会改变函数签名的前提是改变了它接收的参数数量 `_，比如把 ``void a()`` 改成 ``void a(int b = 0)``, 开发者改变其代码的初衷也许是，在不改变「代码兼容性」的同时，又提供了可选 int 参数的余地，然而这终究会破坏函数指针上的兼容性，毕竟函数签名确实变了。 - #. 此外把自带缺省参数的函数地址赋值给指针时，会丢失缺省参数信息。 - #. 我还发现 `滥用缺省参数会害得读者光只看调用代码的话，会误以为其函数接受的参数数量比实际上还要少。 `_ - #. `对使用 C++ 异常处理应具有怎样的态度？ `_ 非常值得一读。 - #. 注意初始化 const 对象时，必须在初始化的同时值初始化。 - #. 用断言代替无符号整型类型，深有启发。 - #. auto 在涉及迭代器的循环语句里挺常用。 - #. `Should the trailing return type syntax style become the default for new C++11 programs? `_ 讨论了 auto 与尾置返回类型一起用的全新编码风格，值得一看。 +#. 实际上，`缺省参数会改变函数签名的前提是改变了它接收的参数数量 `_，比如把 ``void a()`` 改成 ``void a(int b = 0)``, 开发者改变其代码的初衷也许是，在不改变「代码兼容性」的同时，又提供了可选 int 参数的余地，然而这终究会破坏函数指针上的兼容性，毕竟函数签名确实变了。 +#. 此外把自带缺省参数的函数地址赋值给指针时，会丢失缺省参数信息。 +#. 我还发现 `滥用缺省参数会害得读者光只看调用代码的话，会误以为其函数接受的参数数量比实际上还要少。 `_ +#. `对使用 C++ 异常处理应具有怎样的态度？ `_ 非常值得一读。 +#. 注意初始化 const 对象时，必须在初始化的同时值初始化。 +#. 用断言代替无符号整型类型，深有启发。 +#. auto 在涉及迭代器的循环语句里挺常用。 +#. `Should the trailing return type syntax style become the default for new C++11 programs? `_ 讨论了 auto 与尾置返回类型一起用的全新编码风格，值得一看。 diff --git a/google-cpp-styleguide/scoping.rst b/google-cpp-styleguide/scoping.rst index d80424a..d12a8ee 100644 --- a/google-cpp-styleguide/scoping.rst +++ b/google-cpp-styleguide/scoping.rst @@ -1,10 +1,10 @@ 2. 作用域 -------------- +-------- .. _namespaces: 2.1. 名字空间 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~ .. tip:: 鼓励在 ``.cc`` 文件内使用匿名名字空间. 使用具名的名字空间时, 其名称可基于项目名或相对路径. 禁止使用 using 指示（using-directive）。禁止使用内联命名空间（inline namespace）。 @@ -16,13 +16,13 @@ 优点: 虽然类已经提供了（可嵌套的）命名轴线 (YuleFox 注: 将命名分割在不同类的作用域内), 名字空间在这基础上又封装了一层. - + 举例来说, 两个不同项目的全局作用域都有一个类 ``Foo``, 这样在编译或运行时造成冲突. 如果每个项目将代码置于不同名字空间中, ``project1::Foo`` 和 ``project2::Foo`` 作为不同符号自然不会冲突. - + 内联命名空间会自动把内部的标识符放到外层作用域，比如： - + .. code-block:: c++ - + namespace X { inline namespace Y { void foo(); @@ -31,50 +31,49 @@ ``X::Y::foo()`` 与 ``X::foo()`` 彼此可代替。内联命名空间主要用来保持跨版本的 ABI 兼容性。 -缺点: +缺点: + + 名字空间具有迷惑性, 因为它们和类一样提供了额外的 (可嵌套的) 命名轴线. - 名字空间具有迷惑性, 因为它们和类一样提供了额外的 (可嵌套的) 命名轴线. - 命名空间很容易令人迷惑，毕竟它们不再受其声明所在命名空间的限制。内联命名空间只在大型版本控制里有用。 - + 在头文件中使用匿名空间导致违背 C++ 的唯一定义原则 (One Definition Rule (ODR)). 结论: 根据下文将要提到的策略合理使用命名空间. - 2.1.1. 匿名名字空间 -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^ - 在 ``.cc`` 文件中, 允许甚至鼓励使用匿名名字空间, 以避免运行时的命名冲突: .. code-block:: c++ - + namespace { // .cc 文件中 - + // 名字空间的内容无需缩进 enum { kUNUSED, kEOF, kERROR }; // 经常使用的符号 bool AtEof() { return pos_ == kEOF; } // 使用本名字空间内的符号 EOF - + } // namespace - - 然而, 与特定类关联的文件作用域声明在该类中被声明为类型, 静态数据成员或静态成员函数, 而不是匿名名字空间的成员. 如上例所示, 匿名空间结束时用注释 ``// namespace`` 标识. + +然而, 与特定类关联的文件作用域声明在该类中被声明为类型, 静态数据成员或静态成员函数, 而不是匿名名字空间的成员. 如上例所示, 匿名空间结束时用注释 ``// namespace`` 标识. - 不要在 ``.h`` 文件中使用匿名名字空间. 2.1.2. 具名的名字空间 -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^ 具名的名字空间使用方式如下: - 用名字空间把文件包含, `gflags `_ 的声明/定义, 以及类的前置声明以外的整个源文件封装起来, 以区别于其它名字空间: .. code-block:: c++ - + // .h 文件 namespace mynamespace { - + // 所有声明都置于命名空间中 // 注意不要使用缩进 class MyClass { @@ -82,99 +81,98 @@ … void Foo(); }; - + } // namespace mynamespace - + .. code-block:: c++ - + // .cc 文件 namespace mynamespace { - + // 函数定义都置于命名空间中 void MyClass::Foo() { … } - + } // namespace mynamespace - + 通常的 ``.cc`` 文件包含更多, 更复杂的细节, 比如引用其他名字空间的类等. - + .. code-block:: c++ - + #include “a.h” - + DEFINE_bool(someflag, false, “dummy flag”); - + class C; // 全局名字空间中类 C 的前置声明 namespace a { class A; } // a::A 的前置声明 - + namespace b { - + …code for b… // b 中的代码 - + } // namespace b - + - 不要在名字空间 ``std`` 内声明任何东西, 包括标准库的类前置声明. 在 ``std`` 名字空间声明实体会导致不确定的问题, 比如不可移植. 声明标准库下的实体, 需要包含对应的头文件. - 最好不要使用 using 指示，以保证名字空间下的所有名称都可以正常使用. - + .. code-block:: c++ - + // 禁止 —— 污染名字空间 using namespace foo; - 在 ``.cc`` 文件, ``.h`` 文件的函数, 方法或类中, 可以使用 using 声明。 - + .. code-block:: c++ - + // 允许: .cc 文件中 // .h 文件的话, 必须在函数, 方法或类的内部使用 using ::foo::bar; - + - 在 ``.cc`` 文件, ``.h`` 文件的函数, 方法或类中, 允许使用名字空间别名. - + .. code-block:: c++ - + // 允许: .cc 文件中 // .h 文件的话, 必须在函数, 方法或类的内部使用 - + namespace fbz = ::foo::bar::baz; - + // 在 .h 文件里 namespace librarian { //以下别名在所有包含了该头文件的文件中生效。 namespace pd_s = ::pipeline_diagnostics::sidetable; - + inline void my_inline_function() { // namespace alias local to a function (or method). namespace fbz = ::foo::bar::baz; ... } } // namespace librarian - + 注意在 .h 文件的别名对包含了该头文件的所有人可见，所以在公共头文件（在项目外可用）以及它们递归包含的其它头文件里，不要用别名。毕竟原则上公共 API 要尽可能地精简。 - + - 禁止用内联命名空间 - 2.2. 嵌套类 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~ .. tip:: - 当公有嵌套类作为接口的一部分时, 虽然可以直接将他们保持在全局作用域中, 但将嵌套类的声明置于名字空间内是更好的选择. + 当公有嵌套类作为接口的一部分时, 虽然可以直接将他们保持在全局作用域中, 但将嵌套类的声明置于:ref:`namespaces`内是更好的选择. 定义: 在一个类内部定义另一个类; 嵌套类也被称为 *成员类 (member class)*. .. code-block:: c++ - + class Foo { - + private: // Bar是嵌套在Foo中的成员类 class Bar { … }; - + }; 优点: @@ -189,9 +187,8 @@ 不要将嵌套类定义成公有, 除非它们是接口的一部分, 比如, 嵌套类含有某些方法的一组选项. - 2.3. 非成员函数、静态成员函数和全局函数 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. tip:: 使用静态成员函数或名字空间内的非成员函数, 尽量不要用裸的全局函数. @@ -206,15 +203,14 @@ 结论: - 有时, 把函数的定义同类的实例脱钩是有益的, 甚至是必要的. 这样的函数可以被定义成静态成员, 或是非成员函数. 非成员函数不应依赖于外部变量, 应尽量置于某个名字空间内. 相比单纯为了封装若干不共享任何静态数据的静态成员函数而创建类, 不如使用命名空间. - - 定义在同一编译单元的函数, 被其他编译单元直接调用可能会引入不必要的耦合和链接时依赖; 静态成员函数对此尤其敏感. 可以考虑提取到新类中, 或者将函数置于独立库的名字空间内. - - 如果你必须定义非成员函数, 又只是在 ``.cc`` 文件中使用它, 可使用匿名名字空间或 ``static`` 链接关键字 (如 ``static int Foo() {...}``) 限定其作用域. + 有时, 把函数的定义同类的实例脱钩是有益的, 甚至是必要的. 这样的函数可以被定义成静态成员, 或是非成员函数. 非成员函数不应依赖于外部变量, 应尽量置于某个名字空间内. 相比单纯为了封装若干不共享任何静态数据的静态成员函数而创建类, 不如使用:ref:`namespaces`。 + 定义在同一编译单元的函数, 被其他编译单元直接调用可能会引入不必要的耦合和链接时依赖; 静态成员函数对此尤其敏感. 可以考虑提取到新类中, 或者将函数置于独立库的名字空间内. + + 如果你必须定义非成员函数, 又只是在 ``.cc`` 文件中使用它, 可使用匿名:ref:`namespaces`或 ``static`` 链接关键字 (如 ``static int Foo() {...}``) 限定其作用域. 2.4. 局部变量 -~~~~~~~~~~~~~~~ +~~~~~~~~~~~ .. tip:: 将函数变量尽可能置于最小作用域内, 并在变量声明时进行初始化. @@ -222,29 +218,29 @@ C++ 允许在函数的任何位置声明变量. 我们提倡在尽可能小的作用域中声明变量, 离第一次使用越近越好. 这使得代码浏览者更容易定位变量声明的位置, 了解变量的类型和初始值. 特别是，应使用初始化的方式替代声明再赋值, 比如: .. code-block:: c++ - + int i; i = f(); // 坏——初始化和声明分离 int j = g(); // 好——初始化时声明 - + vector v; v.push_back(1); // 用花括号初始化更好 v.push_back(2); - + vector v = {1, 2}; // 好——v 一开始就初始化 注意, GCC 可正确实现了 ``for (int i = 0; i < 10; ++i)`` (``i`` 的作用域仅限 ``for`` 循环内), 所以其他 ``for`` 循环中可以重新使用 ``i``. 在 ``if`` 和 ``while`` 等语句中的作用域声明也是正确的, 如: .. code-block:: c++ - + while (const char* p = strchr(str, ‘/’)) str = p + 1; - + .. warning:: 如果变量是一个对象, 每次进入作用域都要调用其构造函数, 每次退出作用域都要调用其析构函数. - + .. code-block:: c++ - + // 低效的实现 for (int i = 0; i < 1000000; ++i) { Foo f; // 构造函数和析构函数分别调用 1000000 次! @@ -254,35 +250,33 @@ C++ 允许在函数的任何位置声明变量. 我们提倡在尽可能小的 在循环作用域外面声明这类变量要高效的多: .. code-block:: c++ - + Foo f; // 构造函数和析构函数只调用 1 次 for (int i = 0; i < 1000000; ++i) { f.DoSomething(i); } - 2.5. 静态和全局变量 -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ .. tip:: - 禁止使用 ``class`` 类型的静态或全局变量：它们会导致难以发现的 bug 和不确定的构造和析构函数调用顺序。不过 ``constexpr`` 变量除外，毕竟它们又不涉及动态初始化或祈构。 + 禁止使用 ``class`` 类型的静态或全局变量：它们会导致难以发现的 bug 和不确定的构造和析构函数调用顺序。不过 ``constexpr`` 变量除外，毕竟它们又不涉及动态初始化或析构。 静态生存周期的对象，即包括了全局变量，静态变量，静态类成员变量和函数静态变量，都必须是原生数据类型 (POD : Plain Old Data): 即 int, char 和 float, 以及 POD 类型的指针、数组和结构体。 -静态变量的构造函数、祈构函数和初始化的顺序在 C++ 中是不确定的，甚至随着构建变化而变化，导致难以发现的 bug. 所以除了禁用类类型的全局变量，我们也不允许用函数返回值来初始化 POD 变量，除非该函数不涉及（比如 getenv() 或 getpid()）不涉及任何全局变量。（函数作用域里的静态变量除外，毕竟它的初始化顺序是有明确定义的，而且只会在指令执行到它的声明那里才会发生。） +静态变量的构造函数、析构函数和初始化的顺序在 C++ 中是不确定的，甚至随着构建变化而变化，导致难以发现的 bug. 所以除了禁用类类型的全局变量，我们也不允许用函数返回值来初始化 POD 变量，除非该函数不涉及（比如 getenv() 或 getpid()）不涉及任何全局变量。（函数作用域里的静态变量除外，毕竟它的初始化顺序是有明确定义的，而且只会在指令执行到它的声明那里才会发生。） -同理，全局和静态变量在程序中断时会被祈构，无论所谓中断是从 ``main()`` 返回还是对 ``exit()`` 的调用。祈构顺序正好与构造函数调用的顺序相反。但既然构造顺序未定义，那么祈构顺序当然也就不定了。比如，在程序结束时某静态变量已经被祈构了，但代码还在跑——比如其它线程——并试图访问它且失败；再比如，一个静态 string 变量也许会在一个引用了前者的其它变量祈构之前被祈构掉。 +同理，全局和静态变量在程序中断时会被析构，无论所谓中断是从 ``main()`` 返回还是对 ``exit()`` 的调用。析构顺序正好与构造函数调用的顺序相反。但既然构造顺序未定义，那么析构顺序当然也就不定了。比如，在程序结束时某静态变量已经被析构了，但代码还在跑——比如其它线程——并试图访问它且失败；再比如，一个静态 string 变量也许会在一个引用了前者的其它变量析构之前被析构掉。 -改善以上祈构问题的办法之一是用 ``quick_exit()`` 来代替 ``exit()`` 并中断程序。它们的不同之处是前者不会执行任何祈构，也不会执行 ``atexit()`` 所绑定的任何 handlers. 如果您想在执行 ``quick_exit()`` 来中断时执行某 handler（比如刷新 log），您可以把它绑定到 ``_at_quick_exit()``. 如果您想在 ``exit()`` 和 ``quick_exit()`` 都用上该 handler, 都绑定上去。 +改善以上析构问题的办法之一是用 ``quick_exit()`` 来代替 ``exit()`` 并中断程序。它们的不同之处是前者不会执行任何析构，也不会执行 ``atexit()`` 所绑定的任何 handlers. 如果您想在执行 ``quick_exit()`` 来中断时执行某 handler（比如刷新 log），您可以把它绑定到 ``_at_quick_exit()``. 如果您想在 ``exit()`` 和 ``quick_exit()`` 都用上该 handler, 都绑定上去。 综上所述，我们只允许 POD 类型的静态变量，即完全禁用 ``vector`` (使用 C 数组替代) 和 ``string`` (使用 ``const char []``)。 -如果您确实需要一个 ``class` 类型的静态或全局变量，可以考虑在 ``main()`` 函数或 ``pthread_once()`` 内初始化一个指针且永不回收。注意只能用 raw 指针，别用智能指针，毕竟后者的祈构函数涉及到上文指出的不定顺序问题。 - -.. note:: yospaly 译注: - - 上文提及的静态变量泛指静态生存周期的对象, 包括: 全局变量, 静态变量, 静态类成员变量, 以及函数静态变量. +如果您确实需要一个 ``class` 类型的静态或全局变量，可以考虑在 ``main()`` 函数或 ``pthread_once()`` 内初始化一个指针且永不回收。注意只能用 raw 指针，别用智能指针，毕竟后者的析构函数涉及到上文指出的不定顺序问题。 +.. note:: yospaly 译注: + + 上文提及的静态变量泛指静态生存周期的对象, 包括: 全局变量, 静态变量, 静态类成员变量, 以及函数静态变量. 译者 (YuleFox) 笔记 ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -293,7 +287,6 @@ C++ 允许在函数的任何位置声明变量. 我们提倡在尽可能小的 #. 多线程中的全局变量 (含静态成员变量) 不要使用 ``class`` 类型 (含 STL 容器), 避免不明确行为导致的 bug. #. 作用域的使用, 除了考虑名称污染, 可读性之外, 主要是为降低耦合, 提高编译/执行效率. - 译者（acgtyrant）笔记 ~~~~~~~~~~~~~~~~~~~~~~~~