第一章 00-Google+C++编程风格指南.pdfVIP

Google C++ 程风格指南 （一） 背景 Google 开源项目大多使用C++开发。每一个C++程序员也都知道，C++具有很多强大的语言特性，但这种强大 不可避免 导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护。 本指南的目 是通过详细阐述在C++编码时要怎样写、不要怎样写来规避其复杂性。这些规则可在允许代码有效使 用C++语言特性 同时使其易于管理。 风格，也被视为可读性，主要指称管理C++代码 习惯。使用术语风格有 用词不当，因为这些习惯远不止源代码 文件格式这么简单。 使代码易于管理 方法之一是增强代码一致性，让别人可以读懂你 代码是很重要的，保持统一编程风格意味着可以 轻松根据 模式匹配”规则推断各种符号 含义。创建通用的、必需的习惯用语和模式可以使代码更加容易理解，在某 些情况下改变一些编程风格可能会是好 选择，但我们还是应该遵循一致性原则，尽量不这样去做。 本指南 另一个观 是C++特性 臃肿。C++是一门包含大量高级特性 巨型语言，某些情况下，我们会限制甚至 禁止使用某些特性使代码简化，避免可能导致 各种问题，指南中列举了这类特性，并解释说为什么这些特性是被限 制使用的。 由Google 开发的开源项目将遵照本指南约定。 注意：本指南并非C++教程，我们假定读者已经对C++非常熟悉。 头文件 通常，每一个.cc 文件 （C++的源文件）都有一个对应 .h 文件 （头文件），也有一些例外，如单元测试代码和只包 含main() .cc 文件。 正确使用头文件可令代码在可读性、文件大小和性能上大为改观。 下面的规则将引导你规避使用头文件时 各种麻烦。 1. #define 的保护 所有头文件都应该使用#define 防止头文件被多重包含 （multiple inclusion），命名格式当是： PROJECT_PATH_FILE_H_ 为保证唯一性，头文件 命名应基于其所在项目源代码树 全路径。例如，项目foo 中 头文件 foo/src/bar/baz.h 按如下方式保护： #ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_ BAZ_ H_ ... #endif // FOO_ BAR_BAZ_H_ 2. 头文件依赖 使用前置声明（forward declarations）尽量减少.h 文件中#include 数量。 当一个头文件被包含的同时也引入了一项新 依赖（dependency），只要该头文件被修改，代码就要重新编译。如 果你 头文件包含了其他头文件，这些头文件 任何改变也将导致那些包含了你 头文件的代码重新编译。因此，我 们宁可尽量少包含头文件，尤其是那些包含在其他头文件中的。 使用前置声明可以显著减少需要包含 头文件数量。举例说明：头文件中用到类File，但不需要访问File 声明，则 头文件中只需前置声明class File;无需#include file/base/file.h。 在头文件如何做到使用类Foo 而无需访问类 定义？ 1) 将数据成员类型声明为Foo *或Foo ； 2) 参数、返回值类型为Foo 函数只是声明（但不定义实现）； 3) 静态数据成员 类型可以被声明为Foo，因为静态数据成员 定义在类定义之外。 另一方面，如果你 类是Foo 子类，或者含有类型为Foo 非静态数据成员，则必须为之包含头文件。 有时，使用指针成员 （pointer members，如果是scoped_ptr 更好）替代对象成员 （object members） 确 更有意义。 而，这样 做法会降低代码可读性及执行效率。如果仅仅为了少包含头文件，还是不要这样替代 好。 当 ，.cc 文件无论如何都需要所使用类 定义部分，自 也就会包含若干头文件。 译者注：能依赖声明的就不要依赖定义。 3. 内联函数 只有当函数只有10 行甚至更少时才会将其定义为内联函数（inline function）。 定义（Definition）：当函数被声明为内联函数之后，编译器可能会将其内联展开，无需按通常 函数调用机制调 用内联函数。 优点：当函数体比较小的时候，内联该函数可以令目标代码更加高效。对于存取函数（accessor、mutator）以及其 他一些比较短 关键执行函数。 缺点：滥用内联将导致程序变慢，内联有可能是目标代码量或增或减，这取决于被内联 函数的大小。内联较短小 存取函数通常会减少代码量，但内联一个很大 函数 （译者注：如果编译器允许 话）将戏剧性 增加