大型项目开发: 头文件顺序

经验告诉我们。某些编码实践尽管在C++中全然合法，可是绝对不能应用于大型项目环境中。大型项目环境下必须有适当的约束，否则非常easy变得难以控制并不是常难维护（摘自<<大规模C++程序设计>>）。

以下以Chromium中运用的两个Coding Style中定义的头文件顺序为例。

头文件顺序的差异

WebKit/Blink遵循业界标准的定义，事实上也是Lakos在<<大规模C++程序设计>>中建议的顺序 :

编译单元相应的头文件 (Related header file)。
project内的其他头文件。
库及系统头文件。

(Blink特殊的一点是编译单元必须先包括config.h。)

这样做的目的是为避免隐性依赖。每一个头文件都应当做到自包括(Self-Contained, or Self Sufficient), 这样保证用户能直接头文件里理解它的物理依赖。

假设遵循这个顺序，当出现隐性依赖时，是无法编译通过的。

以下这个样例:
my_class.h中依赖了std::string, 但没有显式的包括。当main里先包括标准库的头文件string时，编译是不会出错的。

main.cc

#include <string>
#include <iostream>
#include "my_class.h"

int main(int argc, char* argv[]) {
  MyClass aInstance;
  std::cout << aInstance.value() << std::endl;
}

my_class.h

#ifndef MY_CLASS_H_
#define MY_CLASS_H_
class MyClass {
 public:
  MyClass();
  const std::string& value();
 private:
  std::string value_;
};
#endif

假设遵循上面的规则，就会在编译main.cc时报错:

In file included from main.cc:1:
./my_class.h:6:9: error: use of undeclared identifier 'std'
  const std::string& value();

在一个层次更为清晰的项目下，错误最好归属到作者身上。这里main.cc做为my_class.h的用户。这种错误最好由my_class.h的作者来解决。所以Google定义了例如以下的规则:
• 关联的头文件
• C库头文件
• C++库头文件
• 其他库头文件 * 项目中的其他头文件。
实现例如以下的my_class.cc时就会收到报错: my_class.cc

#include "my_class.h"
#include <string>


MyClass::MyClass()
  :value_("Hello!") {
}

在这种情况下。这个错误将仅仅报给my_class.h相应的编译单元my_class.cc。

In file included from my_class.cc:1:
./my_class.h:6:9: error: use of undeclared identifier 'std'
  const std::string& value();

假设是一个小项目。可能察觉不到这样做的差异。

但在讲求职责清晰，分工协作的大型项目下，它就会变得非常有价值。
这是一个非常小的点，可见大型项目中一些规则定义的冰山一角。

再比方大型项目中的头文件另一些设计上的权衡。比方避免不必要包括头文件会拖慢项目的构建效率。引入了前置声明。但它却在一些场景下会造成歧义(比方前置声明标准库中的类。或者模板类），或者引入一些的维护成本和风险（比方函数的參数变化。须要相应改动前置声明）。Google早期是鼓舞使用前置声明。而如今仅仅是强调在明白带来优点的情况下才建议使用前置声明。

扩展阅读:

Self-sufficient header files in C/C++
Headers and Includes: Why and How
C/C++ include file order/best practices