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 
#include 

#include 
#include 

#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++ 編程風格指南》倡導的原則背後隱藏的目的是：

為了減少隱藏依賴，同時頭文件和其實現文件匹配，應該先包含其首選項（即其對應的頭文件）。

除了首選項外，遵循的是從一般到特殊的原則。不過我覺得《Google C++ 編程風格指南》的順序：C標准庫、C++標准庫、其它庫的頭文件、你自己工程的頭文件中漏了最前面的一項：操作系統級別的頭文件，比如上面的例子sys/types.h估計不能歸入C標准庫，而是Linux操作系統提供的SDK吧。因此我覺得更准確的說法應該是：OS SDK .h , C標准庫、C++標准庫、其它庫的頭文件、你自己工程的頭文件。

之所以要將頭文件所在的工程目錄列出，作用應該是命名空間是一樣的，就是為了區分不小心造成的文件重名。