搜索
背景Google的开源项目大多使用C++开发。每一个C++程序员也都知道，C++具有很多强大的语言特性，但这种强大不可避免的导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护。本指南的目的是通过详细阐述在C++编码时要怎样写、不要怎样写来规避其复杂性。这些规则可在允许代码有效使用C++语言特性的同时使其易于管理。风格，也被视为可读性，主要指称管理C++代码的习惯。使用术语风格有点用词不当，因为这些习惯远不止源代码文件格式这么简单。使代码易于管理的方法之一是增强代码一致性，让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。创建通用的、必需的习惯用语和模式可以使代码更加容易理解，在某些情况下改变一些编程风格可能会是好的选择，但我们还是应该遵循一致性原则，尽量不这样去做。本指南的另一个观点是C++特性的臃肿。C++是一门包含大量高级特性的巨型语言，某些情况下，我们会限制甚至禁止使用某些特性使代码简化，避免可能导致的各种问题，指南中列举了这类特性，并解释说为什么这些特性是被限制使用的。由Google开发的开源项目将遵照本指南约定。注意：本指南并非C++教程，我们假定读者已经对C++非常熟悉。头文件通常，每一个.cc文件（C++的源文件）都有一个对应的.h文件（头文件），也有一些例外，如单元测试代码和只包含main()的.cc文件。正确使用头文件可令代码在可读性、文件大小和性能上大为改观。下面的规则将引导你规避使用头文件时的各种麻烦。1.#define的保护所有头文件都应该使用#define防止头文件被多重包含（multipleinclusion），命名格式当是：PROJECT_PATH_FILE_H_为保证唯一性，头文件的命名应基于其所在项目源代码树的全路径。例如，项目foo中的头文件foo/src/bar/baz.h按如下方式保护：#ifndefFOO_BAR_BAZ_H_#defineFOO_BAR_BAZ_H_...#endif//FOO_BAR_BAZ_H_2.头文件依赖使用前置声明（forwarddeclarations）尽量减少.h文件中#include的数量。当一个头文件被包含的同时也引入了一项新的依赖（dependency），只要该头文件被修改，代码就要重新编译。如果你的头文件包含了其他头文件，这些头文件的任何改变也将导致那些包含了你的头文件的代码重新编译。因此，我们宁可尽量少包含头文件，尤其是那些包含在其他头文件中的。使用前置声明可以显著减少需要包含的头文件数量。举例说明：头文件中用到类File，但不需要访问File的声明，则头文件中只需前置声明classFile;无需#includefile/base/file.h。在头文件如何做到使用类Foo而无需访问类的定义？1)将数据成员类型声明为Foo*或Foo&；2)参数、返回值类型为Foo的函数只是声明（但不定义实现）；3)静态数据成员的类型可以被声明为Foo，因为静态数据成员的定义在类定义之外。另一方面，如果你的类是Foo的子类，或者含有类型为Foo的非静态数据成员，则必须为之包含头文件。有时，使用指针成员（pointermembers，如果是scoped_ptr更好）替代对象成员（objectmembers）的确更有意义。然而，这样的做法会降低代码可读性及执行效率。如果仅仅为了少包含头文件，还是不要这样替代的好。当然，.cc文件无论如何都需要所使用类的定义部分，自然也就会包含若干头文件。译者注：能依赖声明的就不要依赖定义。3.内联函数只有当函数只有10行甚至更少时才会将其定义为内联函数（inlinefunction）。定义（Definition）：当函数被声明为内联函数之后，编译器可能会将其内联展开，无需按通常的函数调用机制调用内联函数。优点：当函数体比较小的时候，内联该函数可以令目标代码更加高效。对于存取函数（accessor、mutator）以及其他一些比较短的关键执行函数。缺点：滥用内联将导致程序变慢，内联有可能是目标代码量或增或减，这取决于被内联的函数的大小。内联较短小的存取函数通常会减少代码量，但内联一个很大的函数（译者注：如果编译器允许的话）将戏剧性的增加代码量。在现代处理器上，由于更好的利用指令缓存（instructioncache），小巧的代码往往执行更快。结论：一个比较得当的处理规则是，不要内联超过10行的函数。对于析构函数应慎重对待，析构函数往往比其表面看起来要长，因为有一些隐式成员和基类析构函数（如果有的话）被调用！另一有用的处理规则：内联那些包含循环或switch语句的函数是得不偿失的，除非在大多数情况下，这些循环或switch语句从不执行。重要的是，虚函数和递归函数即使被声明为内联的也不一定就是内联函数。通常，递归函数不应该被声明为内联的（译者注：递归调用堆栈的展开并不像循环那么简单，比如递归层数在编译时可能是未知的，大多数编译器都不支持内联递归函数）。析构函数内联的主要原因是其定义在类的定义中，为了方便抑或是对其行为给出文档。4.-inl.h文件复杂的内联函数的定义，应放在后缀名为-inl.h的头文件中。在头文件中给出内联函数的定义，可令编译器将其在调用处内联展开。然而，实现代码应完全放到.cc文件中，我们不希望.h文件中出现太多实现代码，除非这样做在可读性和效率上有明显优势。如果内联函数的定义比较短小、逻辑比较简单，其实现代码可以放在.h文件中。例如，存取函数的实现理所当然都放在类定义中。出于实现和调用的方便，较复杂的内联函数也可以放到.h文件中，如果你觉得这样会使头文件显得笨重，还可以将其分离到单独的-inl.h中。这样即把实现和类定义分离开来，当需要时包含实现所在的-inl.h即可。-inl.h文件还可用于函数模板的定义，从而使得模板定义可读性增强。要提醒的一点是，-inl.h和其他头文件一样，也需要#define保护。5.函数参数顺序（FunctionParameterOrdering）定义函数时，参数顺序为：输入参数在前，输出参数在后。C/C++函数参数分为输入参数和输出参数两种，有时输入参数也会输出（译者注：值被修改时）。输入参数一般传值或常数引用（constreferences），输出参数或输入/输出参数为非常数指针（non-constpointers）。对参数排序时，将所有输入参数置于输出参数之前。不要仅仅因为是新添加的参数，就将其置于最后，而应该依然置于输出参数之前。这一点并不是必须遵循的规则，输入/输出两用参数（通常是类/结构体变量）混在其中，会使得规则难以遵循。6.包含文件的名称及次序将包含次序标准化可增强可读性、避免隐藏依赖（hiddendependencies，译者注：隐藏依赖主要是指包含的文件中编译时），次序如下：C库、C++库、其他库的.h、项目内的.h。项目内头文件应按照项目源代码目录树结构排列，并且避免使用UNIX文件路径.（当前目录）和..（父目录）。例如，google-awesome-project/src/base/logging.h应像这样被包含：#includebase/logging.hdir/foo.cc的主要作用是执行或测试dir2/foo2.h的功能，foo.cc中包含头文件的次序如下：dir2/foo2.h（优先位置，详情如下）C系统文件C++系统文件其他库头文件本项目内头文件这种排序方式可有效减少隐藏依赖，我们希望每一个头文件独立编译。最简单的实现方式是将其作为第一个.h文件包含在对应的.cc中。dir/foo.cc和dir2/foo2.h通常位于相同目录下（像base/basictypes_unittest.cc和base/basictypes.h），但也可在不同目录下。相同目录下头文件按字母序是不错的选择。举例来说，google-awesome-project/src/foo/internal/fooserver.cc的包含次序如下：#includefoo/public/fooserver.h//优先位置#includesys/types.h#includeunistd.h#includehash_map#includevector#includebase/basictypes.h#includebase/commandlineflags.h#includefoo/public/bar.h______________________________________译者：英语不太好，翻译的也就不太好。这一篇主要提到的是头文件的一些规则，总结一下：1.避免多重包含是学编程时最基本的要求；2.前置声明是为了降低编译依赖，防止修改一个头文件引发多米诺效应；3.内联函数的合理使用可提高代码执行效率；4.-inl.h可提高代码可读性（一般用不到吧:D）；5.标准化函数参数顺序可以提高可读性和易维护性（对函数参数的堆栈空间有轻微影响，我以前大多是相同类型放在一起）；6.包含文件的名称使用.和..虽然方便却易混乱，使用比较完整的项目路径看上去很清晰、很条理，包含文件的次序除了美观之外，最重要的是可以减少隐藏依赖，使每个头文件在“最需要编译”（对应源文件处:D）的地方编译，有人提出库文件放在最后，这样出错先是项目内的文件，头文件都放在对应源文件的最前面，这一点足以保证内部错误的及时发现了。作用域1.命名空间（Namespaces）在.cc文件中，提倡使用不具名的命名空间（unnamednamespaces，译者注：不具名的命名空间就像不具名的类一样，似乎被介绍的很少:-(）。使用具名命名空间时，其名称可基于项目或路径名称，不要使用using指示符。定义：命名空间将全局作用域细分为不同的、具名的作用域，可有效防止全局作用域的命名冲突。优点：命名空间提供了（可嵌套）命名轴线（nameaxis，译者注：将命名分割在不同命名空间内），当然，类也提供了（可嵌套）的命名轴线（译者注：将命名分割在不同类的作用域内）。举例来说，两个不同项目的全局作用域都有一个类Foo，这样在编译或运行时造成冲突。如果每个项目将代码置于不同命名空间中，project1::Foo和project2::Foo作为不同符号自然不会冲突。缺点：命名空间具有迷惑性，因为它们和类一样提供了额外的（可嵌套的）命名轴线。在头文件中使用不具名的空间容易违背C++的唯一定义原则（OneDefinitionRule(ODR)）。结论：根据下文将要提到的策略合理使用命名空间。1)不具名命名空间（UnnamedNamespaces）在.cc文件中，允许甚至提倡使用不具名命名空间，以避免运行时的命名冲突：namespace{//.cc文件中//命名空间的内容无需缩进enum{UNUSED,EOF,ERROR};//经常使用的符号boolAtEof(){returnpos_==EOF;}//使用本命名空间内的符号EOF}//namespace然而，与特定类关联的文件作用域声明在该类中被声明为类型、静态数据成员或静态成员函数，而不是不具名命名空间的成员。像上文展示的那样，不具名命名空间结束时用注释//namespace标识。不能在.h文件中使用不具名命名空间。2)具名命名空间（NamedNamespaces）具名命名空间使用方式如下：命名空间将除文件包含、全局标识的声明/定义以及类的前置声明外的整个源文件封装起来，以同其他命名空间相区分。//.h文件namespacemynamespace{//所有声明都置于命名空间中//注意不要使用缩进classMyClass{public:...voidFoo();};}//namespacemynamespace//.cc文件namespacemynamespace{//函数定义都置于命名空间中voidMyClass::Foo(){...}}//namespacemynamespace通常的.cc文件会包