前言：神乎其技，功到自成
C 語言給予程式設計師極大自由，也要求極高自律。本文整理經典「十大建議」與反面教材「如何寫爛代碼」，以幽默犀利的筆觸揭示工程本質。
一、寫好 C 程式的 10 條鐵律
- 頻繁跑 Lint：靜態分析工具的思慮遠超人腦，編譯器不報錯不代表沒坑。
- 拒絕 NULL 指標解參考：混沌癡顛必俟君於彼岸——防禦性檢查不可省。
- 強制轉型函數參數：即使你自以為類型無誤，也要顯式轉換匹配原型，避免隱式轉換埋下血債。
- 補全頭檔缺失的回傳類型：舊式頭檔常省略回傳型別，自行宣告以防不測。
- 親核陣列與字串越界：古人云「所期者短，所獲者長」，緩衝區溢出是 C 語言頭號殺手。
- 檢查每一個錯誤碼：哪怕讓代碼膨脹數倍、手指酸痛，也不可假設「異常難得一見」。傲慢必被懲戒。
- 善用庫函數，勿重造輪子：代碼更短、更易讀、心境更恬淡。標準庫經過無數雙眼睛審視。
- 括號與縮進：為維護者著想：聰明才智用於解決問題，而非製造迷霾。清晰架構是專業素養。
- 外部識別符前六字元唯一：舊式連結器限制看似粗陋，違之將來連結舊碼時抓耳撓腮。
- 拒絕平台鎖定迷思：宣稱「普天之下莫非 VAX」者，當摒棄之。程式碼應具備可移植性，而非綁定特定硬體。
二、如何寫出最爛的 C 程式（反面教材）
- 重寫標準庫並改成晦澀名字
- 依賴不可移植的私有庫
- 註解寫成
// printf("Hello world"); 這種廢話
- 鄙視換行與縮進，內嵌大量組合語言
- 拒絕使用者介面，認為使用者不配
- 從別人代碼隨機複製註解湊數
- 濫用前置處理器宏替代函數
- 相信編譯器會搞定一切細節
三、如何測試最爛的 C 程式
- 編譯通過就怪別人代碼
- 全是自己寫的就怪庫
- 錯誤報告是污衊純潔名譽的謊言
- 測試員能讀懂代碼說明寫爛功夫不到家
- 怪公司不買 C++ 編譯器
- 隨機增刪空行重新編譯試運氣
- 改寫組合語言讓沒人能定位錯誤
結語
這些看似調侃的條款，實則直指工程核心：嚴謹、謙遜、可維護、可移植。寫代碼前先想「半年後的我能看懂嗎？」，這就是最好的準則。
