catch the digital flow｜北极冰仔部落格

Google C++ 编程风格指南（1）：头文件（2）

• -inl.h 文件
• 函数的参数顺序
• 头文件名称的顺序

-inl.h 文件

当需要的时候，你应该使用带有 -inl.h 后缀的名字来定义复杂的内联函数。

内联函数的定义需要放在一个头文件里，使得编译器在发生函数调用的地点展开函数定义。尽管如此，实现代码出现在 .cc 文件中更为合适，我们不想让 .h 文件拥有太多的代码，除非那样做可以提高可读性或是性能。

如果一个内联函数的定义很短小，你应该将其放在 .h 文件中。例如，accessors 和 mutators 应该始终放在类定义之内。更加复杂的内联函数也应该放在一个 .h 文件内以方便实现和调用，尽管这样会造成 .h 文件太笨重。解决方法就是将这些代码放入一个单独的 -inl.h 文件内，虽然会导致它与类的定义相分离，但仍然允许实现部分在必要的时候被包含。

-inl.h 文件的另一个用法是定义模板函数，它用来保持你的模板定义容易被读懂。

不要忘记像任何其它头文件那样，给 -inl.h 写一个 #define 宏。

函数的参数顺序

定义一个函数时，参数顺序应该是：先输入、后输出。

C/C++ 函数的参数既可以是输入，也可以是输出，或者二者皆是。输入参数通常是值或 const 引用，输出参数通常是 non-const 指针。当为函数的参数排序时，应把所有只作为输入的参数放在任意输出参数前面。尤其不要把新添加的参数放在函数的最后仅仅因为它们是新添加的；把新添加的输入参数放在输出参数之前。

这不是一条死规矩。那些同时既是输入又是输出的参数（经常是类/结构体）会把水搅浑。所以，遇到这样的函数时，你可以不完全遵守这一条。

头文件名称的顺序

按标准顺序使用头文件会增强代码的可读性，并可避免引入隐式对 C 库、C++ 库或其它库的、你的库的头文件的依赖。

一个工程的所有头文件都应该放入工程源代码目录下，而不要使用 UNIX 目录的快捷方式：.（当前目录）或 ..（上级目录）。例如：google-awesome-project/src/base/logging.h 应该被这样包含：

在一个主要目的是实现或测试 dir2/foo2.h 的 dir/foo.cc 文件中，将头文件按以下顺序包含：

1. dir2/foo2.h（优先位置）
2. C 系统文件
3. C++ 系统文件
4. 其它库的头文件
5. 你的工程的头文件

优先位置会减少隐式依赖。我们希望每个头文件被分别编译，达到这个目的的最简单途径就是保证它们是某个 .cc 文件中包含的第一个 .h 文件。

dir/foo.cc 和 dir2/foo2.h 经常在相同的目录下（例：base/basictypes_unittest.cc 和 base/basictypes.h），但是也可以是不同的目录。

最好在每个片段中按字母顺序包含头文件。

例：google-awesome-project/src/foo/internal/fooserver.cc 中包含的头文件看上去差不多是这个样子：