google C++编程风格对头文件的包含顺序作出如下指示:
(1)为了加强可读性和避免隐含依赖,应使用下面的顺序:C标准库、C++标准库、其它库的头文件、你自己工程的头文件。不过这里最先包含的是首选的头文件,即例如a.cpp文件中应该优先包含a.h。首选的头文件是为了减少隐藏依赖,同时确保头文件和实现文件是匹配的。具体的例子是:假如你有一个cc文件(linux平台的cpp文件后缀为cc)是google-awesome-project/src/foo/internal/fooserver.cc,那么它所包含的头文件的顺序如下:
#include "foo/public/fooserver.h" //首选的头文件放在第一位
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"
隐含依赖又叫作隐藏依赖,即一个头文件依赖其它头文件。例如:
//A.h
struct BS bs;
...
//B.h
struct BS{
....
};
//在A.c中,这样会报错
#include A.h
#include B.h
//先包含B.h就可以
#include B.h
#include A.h
这样就叫”隐藏依赖”。如果先包含A.h就可以发现隐藏依赖,所以各种规范都要求自身的头文件放在第一个,就能发现隐藏依赖。解决办法就是在A.h中包含B.h,而不是在A.c中再包含。
(2)在包含头文件时应该加上头文件所在工程的文件夹名,即假如你有这样一个工程base,里面有一个logging.h,那么外部包含这个头文件应该这样写:#include "base/logging.h"
,而不是#include "logging.h"
。
我们看到《Google C++ 编程风格指南》倡导原则背后隐藏的目的是: (1) 为了减少隐藏依赖,源文件应该先包含其对应的头文件(本文称之为首选项)。 (2)除了首选项外,遵循从一般到特殊的原则。不过我觉得《Google C++ 编程风格指南》的顺序:C标准库、C++标准库、其它库的头文件、自己工程的头文件,在最前面漏了一项:操作系统级别的头文件。比如上面例子sys/types.h不能归入C标准库,而是Linux操作系统提供的SDK。因此我觉得更准确的说法应该是:OS SDK .h , C标准库、C++标准库、其它库的头文件、你自己工程的头文件。 (3)之所以要将头文件所在工程目录列出,作用同命名空间一样,为了解决头文件重名问题。
[1]http://www.cnblogs.com/clever101/archive/2011/08/21/2147892.html [2]http://www.cnblogs.com/frydsh/p/3466660.html