google C++编程风格对头文件的包括顺序作出例如以下指示：
（1）为了加强可读性和避免隐含依赖，应使用以下的顺序：C标准库、C++标准库、其他库的头文件、你自己project的头文件。只是这里最先包括的是首选的头文件，即比如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）在包括头文件时应该加上头文件所在project的文件夹名，即假如你有这样一个projectbase。里面有一个logging.h，那么外部包括这个头文件应该这样写：#include "base/logging.h"，而不是#include "logging.h"。
我们看到《Google C++ 编程风格指南》倡导原则背后隐藏的目的是：
（1） 为了降低隐藏依赖，源文件应该先包括其相应的头文件（本文称之为首选项）。
（2）除了首选项外。遵循从一般到特殊的原则。
只是我认为《Google C++ 编程风格指南》的顺序：C标准库、C++标准库、其他库的头文件、自己project的头文件。在最前面漏了一项：操作系统级别的头文件。比方上面样例sys/types.h不能归入C标准库。而是Linux操作系统提供的SDK。
因此我认为更准确的说法应该是：OS SDK .h , C标准库、C++标准库、其他库的头文件、你自己project的头文件。
（3）之所以要将头文件所在project文件夹列出，作用同命名空间一样。为了解决头文件重名问题。
參考文献
[1]http://www.cnblogs.com/clever101/archive/2011/08/21/2147892.html
[2]http://www.cnblogs.com/frydsh/p/3466660.html