中文版 Google C++代码风格规范.pdf

Google C++ 风格指南 - 中文版 1. 头文件¶ 通常每一个 .cc文件都有一个对应的 .h文件. 也有一些常见例外, 如单元测试代码和只包含main() 函数的 .cc文件. 正确使用头文件可令代码在可读性、文件大小和性能上大为改观. 下面的规则将引导你规避使用头文件时的各种陷阱. 1.1. #define 保护¶ Tip 所有头文件都应该使用#define 防止头文件被多重包含, 命名格式当是: 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_ 1.2. 头文件依赖¶ Tip 能用前置声明的地方尽量不使用#include. 当一个头文件被包含的同时也引入了新的依赖, 一旦该头文件被修改, 代码就会被重新编译. 如果这个头文件又包含了其他头文件, 这些头文 件的任何改变都将导致所有包含了该头文件的代码被重新编译. 因此, 我们倾向于减少包含头文件, 尤其是在头文件中包含头文件. 使用前置声明可以显著减少需要包含的头文件数量. 举例说明: 如果头文件中用到类File, 但不需要访问File 类的声明, 头文件中只需前 置声明 class File; 而无须#include file/base/file.h. 不允许访问类的定义的前提下, 我们在一个头文件中能对类Foo 做哪些操作?  我们可以将数据成员类型声明为Foo * 或Foo .  我们可以将函数参数/ 返回值的类型声明为Foo (但不能定义实现).  我们可以将静态数据成员的类型声明为Foo, 因为静态数据成员的定义在类定义之外. 反之, 如果你的类是Foo 的子类, 或者含有类型为Foo 的非静态数据成员, 则必须包含Foo 所在的头文件. 有时, 使用指针成员(如果是scoped_ptr 更好) 替代对象成员的确是明智之选. 然而, 这会降低代码可读性及执行效率, 因此如果仅仅为了 少包含头文件，还是不要这么做的好. 当然 .cc文件无论如何都需要所使用类的定义部分, 自然也就会包含若干头文件. 1.3. 内联函数¶ Tip 只有当函数只有10 行甚至更少时才将其定义为内联函数. 定义: 当函数被声明为内联函数之后, 编译器会将其内联展开, 而不是按通常的函数调用机制进行调用. 优点: 当函数体比较小的时候, 内联该函数可以令目标代码更加高效. 对于存取函数以及其它函数体比较短, 性能关键的函数, 鼓励使用 内联. 缺点: 滥用内联将导致程序变慢. 内联可能使目标代码量或增或减, 这取决于内联函数的大小. 内联非常短小的存取函数通常会减少代码 大小, 但内联一个相当大的函数将戏剧性的增加代码大小. 现代处理器由于更好的利用了指令缓存, 小巧的代码往往执行更快。 结论: 一个较为合理的经验准则是, 不要内联超过10 行的函数. 谨慎对待析构函数, 析构函数往往比其表面看起来要更长, 因为有隐含 的成员和基类析构函数被调用! 另一个实用的经验准则: 内联那些包含循环或switch 语句的函数常常是得不偿失(除非在大多数情况下, 这些循环 或 switch 语句从不被执行). 有些函数即使声明为内联的也不一定会被编译器内联, 这点很重要; 比如虚函数和递归函数就不会被正常内联. 通常, 递归函数不 应该声明成内联函数. （YuleFox 注: 递归调用堆栈的展开并不像循环那么简单, 比如递归层数在编译时可能是未知的, 大多数编 译器都不支持内联递归函数). 虚函数内联的主要原因则是想把它的函数体放在类定义内, 为了图个方便, 抑或是当作文档描述其 行为, 比如精短的存取函数. 1.4. -inl.h 文件¶ Tip 复杂的内联函数的定义, 应放在后缀名为 -inl.h 的头文件中. 内联函数的定义必须放在头文件中, 编译器才能在调用点内联展开定义. 然而, 实现代码理论上应该放在 .cc文件中, 我们不希望 .h文件 中有太多实现代码, 除非在可读性和性能上有明显优势. 如果内联函数的定