C語言程式設計十大戒律與反面教材

前言：大道至簡，功到自然成

C語言雖老，但其核心哲學——「信任程式設計師」與「貼近硬體」——至今仍是系統級開發的基石。寫好C程式不在於花俏技巧，而在於紀律與細節。本文整理自經典編程智慧，呈現十大建議與「如何寫爛代碼」的反面教材，助你避坑提效。

十大寫好C程式的秘籍

1. 善用 Lint，靜態分析勝過人工審視

編譯器只檢查語法，Lint 類工具能發現潛在邏輯錯誤、類型不匹配、未使用變量等深層問題。將其納入 CI 流程，讓機器做機器擅長的事。

2. 絕不解引用空指針

NULL 指針解引用是未定義行為（UB）的重災區。永遠在使用前檢查指針有效性，現代 C 建議使用 static_assert 或斷言輔助防禦。

3. 強制類型轉換函數參數，消除隱式轉換隱患

即使你知道原型匹配，也要顯式轉型（如 (int*)ptr）。隱式轉換在參數提升、變參函數中極易埋下數據截斷或棧錯亂的炸彈。

4. 補全頭文件中的返回類型聲明

舊式 C 允許隱式 int 返回，現代標準禁止。頭文件必須完整聲明返回類型，防止調用端默認 int 導致棧平衡崩潰。

5. 親自檢查數組邊界，聖人也難救越界之禍

C 無邊界檢查，緩衝區溢出是頭號安全漏洞。寫循環時時刻刻驗證索引範圍，sizeof(arr)/sizeof(arr[0]) 應成肌肉記憶。

6. 嚴謹檢查每一個錯誤碼返回值

哪怕代碼膨脹、手指酸痛，也要 if (ret != OK) handle_error();。「這錯誤不可能發生」正是災難降臨的前奏。

7. 研習標準庫，切勿重複造輪子

qsort、bsearch、strncpy 等經過數十年優化，正確性與效率遠超自寫版本。用好標準庫，代碼更短、更易讀、更穩健。

8. 善用括號與縮進，為維護者鋪路

代碼給人看，順便給機器跑。清晰的結構勝過任何註釋；把智慧用在演算法上，別用在製造迷宮上。

9. 外部標識符前六字符須唯一

舊式鏈接器只看前 6 字符且不區分大小寫。雖現代工具鏈已放寬，但遵循此規範能保證極致移植性，避免符號衝突的神秘錯誤。

10. 摒棄「天下皆 VAX」的平台迷思

別假設 int 32 位、指針 64 位、小端序、ASCII 字符集。寫可移植代碼，使用 stdint.h 定寬類型，htonl/ntohl 處理網絡序。

反面教材：如何寫出最爛的 C 程式

1. 重寫標準庫並改晦澀名：把 malloc 改名 alloc_mem_magic，讓維護者猜謎。
2. 綁定專有、不可移植庫：鎖死平台，職業生涯也鎖死了。
3. 在顯而易見處寫廢話註釋：printf("Hello"); // 打印 Hello，侮辱智商。
4. 拒絕換行與縮進，內嵌彙編裝高手：可讀性歸零，除錯難度指數級上升。
5. 鄙視用戶界面，拒絕交互：程式是給人用的，別寫只能跑在作者腦中的代碼。
6. 從別處複製無關註釋湊數：誤導維護者，製造認知負擔。
7. 濫用宏替換庫函數：宏無類型檢查、副作用多、調試難，能用函數/內聯函數就別用宏。
8. 盲信編譯器優化，不關心細節：UB 代碼在不同優化等級下行為截然不同，編譯器不背鍋。

反面教材：如何測試最爛的 C 程式

1. 編譯通過即宣稱無錯：編譯 ≠ 正確，警告全開才是起點。
2. 甩鍋給庫/編譯器/作業系統：先證明自己代碼無誤，再質疑外部。
3. 把錯誤報告視為人身攻擊：防禦性編程的核心是接納批評。
4. 故意寫得讓人看不懂：混淆視為職業保障，實則是職業自殺。
5. 賭 C++ 編譯器能修復 C 的錯：語言遷移需重構，非編譯器魔法。
6. 隨機增刪空行重編試運氣：非確定性調試，純屬浪費生命。
7. 改寫彙編隱藏錯誤：沒人能審計，也沒人能維護，包括未來的你。

總結

C語言給予極大自由，也要求極大自律。十大秘籍是護城河，反面教材是照妖鏡。寫代碼前問自己：「這樣寫，半年後的我能秒懂嗎？異平台能跑嗎？輸入異常會炸嗎？」 以此自省，代碼自然長壽。