原文地址：https://www.amobbs.com/thread-5675247-1-1.html
認真說起來，頭文件（Header File）是個短命的傢伙——就整個編譯過程來說，它的壽命是最短的。
爲什麼這麼說呢？關於頭文件的話題，討論起來那可是“孩子沒娘，說來話長了”，既然是閒聊、你也不是等着這篇文章救命，那就不妨從頭開始說起——先假設讀者們都是不瞭解編譯基本過程的初學者。
一個編譯（Compilation）過程通常至少分爲三個階段：預編譯（Precompiling）、編譯（Make）和鏈接（Linking）。他們就像一個流水線一環套一環——前一工序的輸出是後一工序的輸入。這本沒有什麼稀奇的，但對於程序員來說，這個過程中有幾個基本常識是需要記住的：
- C語言編譯的基本單位（Compilation Unit）是 C源文件 （而並沒有頭文件）；
- 同一個工程中，不同C源文件的編譯是彼此獨立的（毫不相干的）；
- 頭文件在預編譯階段就已經合併到對應的C源文件中了，和所有的宏以及條件編譯一樣，到了編譯階段，所有的頭文件、宏都是不存在的，已經被替換爲對應的內容和常量了。
理解這三點，基本上已經可以解決很多我們日常編碼過程中存在的很多疑問，比如：
-
Q1：爲什麼不能C語言頭文件裏面定義變量或者函數的實體？
-
Q2：爲什麼有的時候宏的先後順序並不那麼重要？
-
Q3：爲什麼可以在源代碼的任意位置（另起一行後）定義宏，甚至是include別的頭文件？
推薦大家基於前面的三個事實自己思考。頭文件裏可以放什麼呢？這是個值得討論的問題：
-
各類宏
-
函數的聲明（也就是 extern xxxxx）
-
全局變量的聲明（也就是 extern xxxx）
然而，值得說明的是，這裏有一個編碼規則值得你去遵守：頭文件裏堅決不要放全局變量有關的任何東西（硬要加，也必須是const類型的，比如各類接口）。 -
類型定義（typedef, struct, union 之類的）
-
static 的變量實體和函數實體。
這個可以有，爲啥呢？因爲即便多個c源文件包含同一個頭文件導致同樣的函數和變量實體存在多份，但static 的另外一個名字 “private” 可以保證每一份變量和函數實體都是彼此獨立的，都是每個c源代碼的私人財產——你可以有，我也可以有。“哎？你也有啊，真巧哎，我也有……” -
inline 的函數
這個和static是一個道理。
頭文件裏面不能放函數的實體，想必原因大部分人都知道了，這裏就不再贅述。但頭文件裏不放（非const）的全局變量的聲明，這怎麼玩？這裏需要說明一下，頭文件裏不是不能放（非const）的全局變量聲明，而是我提供了一個人爲的規定（規範），建議不要放任何（非const）的全局變量到頭文件裏，具體原因和解決方案，我們在別的帖子裏再討論（其實有人討論過，大約就是，如何避免使用全局變量）——是的，避免使用（非const）的全局變量是可以做到的——這裏也不再贅述。說了這麼多廢話，我們真正要討論的內容還沒有開始：
如何建立頭文件的使用規則，使其即靈活、使用方便，又靈活且便於擴展（模塊化）——符合面向接口開發的要求，方便我們 建立黑盒子？
簡而言之，如何讓頭文件的使用不再頭疼；永遠告別循環包含；方便代碼的移植？
首先，思考一個簡單的問題？爲什麼我們要用頭文件？答案其實很簡單，因爲每個.c文件都是獨立編譯的，因此需要在源代碼級別傳遞一些信息，類似一羣人在嘮嗑：
源代碼A： 我定義了一個函數，你們哥幾個要用麼？
源代碼B和源代碼C： 我們要用啊，函數原型（prototype）什麼樣子啊？
源代碼A： 你們不用費腦經記（抄下來），我都寫好了，放在一個頭文件裏了，你們直接include就可以了。
源代碼B和源代碼C： 這個敢情方便。那你頭文件放哪裏了？
源代碼A： 有兩種方式，要麼你直接到我這裏來拿（指定路徑）；要麼你找編譯器問（編譯器指定搜索路徑）。
源代碼D： 你們整這麼麻煩做什麼？你直接告訴我原型，我抄下來，不就不用問這個問那個，還包含文件什麼的，真麻煩。
源代碼A： D啊，你老想耍小聰明，萬一我更新了你不知道怎麼辦？我有義務告訴你麼？並沒有。
源代碼B和源代碼C： 是啊，是啊，A以後估計要外包了，不在這裏了，到時候有變化，都記錄在頭文件裏，你本地放一個，沒法及時同步的。
源代碼D： 我不聽！我不聽！我不聽……
是不是很有畫面感？拋開捂着耳朵的D，我們回到討論的話題——既然頭文件是用來交換信息的，那麼如果把所有的信息都放在一起，大家需要的時候各取所需，豈不美哉？——基於這種思想，幾乎所有人都見過把所有變量、函數、宏、類型定義都放到一個叫做system.h的頭文件裏的做法。你有這麼做過麼？不要不好意思，幾乎所有人都這麼做過——因爲實在太方便了，世界大同，挺好，直到你嘗試和別人一起合作開發系統，並試圖在不同項目間複用一些代碼的時候：
“何首烏藤和木蓮藤纏絡着”……對於這種情況，我們叫做耦合。“是要找個時間來理一理了”，你對自己說，然後長嘆了一口氣，發現這句話其實很早之前就說過了。想到還有更奇葩的循環包涵的問題，你不得不感嘆，頭文件真的是個頭疼的東西——要不我們還是不用了吧？直接抄下來貌似更簡單啊——源程序D癡癡的笑了。
那麼，如何解決這個問題呢？其實，從實踐經驗來看，頭文件的用途分爲兩大類：
站在C源文件的視角上：
從外部向C源文件內部 輸入配置信息——我們把這類頭文件叫做配置頭文件(Configuration Header File)。需要強調的是，信息的流動方向是 從外向內，所以又可以簡單的理解爲輸入性的頭文件（Header File for information input）。常見的app_cfg.h 就是典型的配置頭文件。
從 C源文件內部向外 輸出接口信息（全局函數、類型，宏定義等信息）——我們把這類頭文件叫做接口頭文件（Interface Header File）。需要強調的是，信息的流動方向是 從內向外，所以又可以簡單的理解爲輸出性的頭文件（Header File for information output）。常見的, spi.husart.h, device.h, stdint.h 就是典型的接口頭文件。
輸入和輸出兩個不同的職能如果被放在同一個頭文件裏，就有極大的風險產生循環包含或者交叉引用（兩個相反方向的箭頭產生閉合的圓圈）。
system.h實際上就是一個混淆信息流動方向的例子。這就是本質上依賴system.h的工程 模塊不好拆分的原因。一般來說，爲了“降低”循環包含的風險，同時又爲了尊重常見模塊封裝的習慣，我們會人爲的規定：
- 模塊內部的各類文件“允許”包含模塊的接口頭文件；
- 模塊內部的各類文件“應該”包含模塊自己的配置頭文件；
- 除極少數情況外，系統中所有的配置頭文件都“應該避免”包含任何街口頭文件。
簡單的來說，這三條規則就是允許兩個信息流單向的進行混合：也就是，配置頭文件的信息可以單向的流向接口頭文件；但反過來卻絕對禁止，這就從源頭上極大的降低了發生“循環包含”的概率。但即便如此，還有另外一類問題單純依靠拆分頭文件是不能解決的，這就是頭文件的“交叉引用”問題。