#include <>與#include ””的區別
一種是在包含指令#include後面”<>”將頭文件名括起來。這種方式用於標準或系統提供的頭文件，到保存系統標準頭文件的位置查找頭文件。
另一種是在包含指令#include後用雙引號””將頭文件包括起來。這種方式常用與程序員自己的頭文件。用這種格式時，C編譯器先查找當前目錄是否有指定名稱的頭文件，然後在從標準頭文件目錄中查找。
在使用標準的頭文件包含順序可增強可讀性，避免隱藏依賴。
#include的路徑
項目內頭文件應按照項目源代碼目錄樹結構排列，避免使用UNIX特殊的快捷目錄.（當前目錄）或…（上級目錄）。
例如，project/src/base/logging.h應該按照如下方式包含：
#include "base/logging.h"
#include的頭文件包含順序
如果dir/foo.c的主要作用是實現或者測試dir2/foo2.h的功能，foo.c中包含頭文件的次序如下：
- 1.dir2/foo2.h（優先位置）
- 2.C系統文件
- 3.C++系統文件
- 4.其他庫的.h文件
- 5.本項目內的.h文件
這種優先的順序排序保證當dir2/foo2.h遺漏某些必要的庫時，dir/foo.c的構件會立刻中止。因此這一條規則保證維護這些文件的人們首先看到構建中止的消息而不是維護其他包的人們。
如果依賴的符號被哪些頭文件所定義，就應該包含哪些頭文件，前置聲明除外。比如要用到bar.h中的某個符號，哪怕包含的foo.h文件中已經包含了bar.h，也照樣包含bar.h，除非foo.h有明確說明它會自動提供bar.h中的符號。
舉例
progect/foo/internal/fooserver.c的包含次序如下：
#include "foo/public/fooserver.h" //優先位置
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#icnlude "base/commandlineflags"
#include "foo/public/bar.h"
以上是《Google C++ 編程風格指南》的觀點，在《C++編程思想》則包含另一種觀點。
《C++ 編程思想》認爲頭文件的包含順序是從“最特殊到最一般”。
- 1.dir2/foo2.h （接上例）
- 2.本項目內的.h文件
- 3.其他庫的.h文件
- 4.C++系統文件
- 5.C系統文件
這是爲了保證.h文件的組成部分不被它自身解析。因爲被自身解析缺乏明確提供的聲明或者定義。
總結
《Google C++ 編程風格指南》和《C++ 編程思想》倡導的包含頭文件的順序各有優點，《Google C++ 編程風格指南》應該能大量減少隱藏的頭文件依賴，而《C++編程思想》則很容易讓你清楚知道你所定義的接口是否和系統庫及第三方庫發生衝突。
隱藏依賴：即一個頭文件依賴其他文件。所以無論是《Google C++ 編程風格指南》還是《C++ 編程思想》都是將自身的頭文件放在第一位，因爲這樣可以便於發現隱藏依賴。