編程精粹 ─ Microsoft編寫優質無錯C程序秘訣
下載：Writing Clean Code ─ Microsoft Techniques for Developing Bug-free C Programs 中文版-------------------------------------------------------------------------------------------------------------
附錄A 編碼檢查表
本附錄給出的問題列表，總結了本書的所有觀點。使用本表的最好辦法是花兩周時間評審一下你的設計和編碼實現。先花幾分鐘時間看一看列表，一旦熟悉了這些問題，就可以靈活自如地按它寫代碼了。此時，就可以把表放在一邊了。
一般問題 1、你是否為程序建立了DEBUG版本？
2、你是否將發現的錯誤及時改正了？
3、你是否堅持徹底測試代碼．即使耽誤了進度也在所不惜？
4、你是否依靠測試組為你測試代碼？
5、你是否知道編碼的優先順序？
6、你的編譯程序是否有可選的各種警告？
關于將更改歸并到主程序
1、你是否將編譯程序的警告（包括可選的）都處理了？
2、你的代碼是否未用Lint
3、你的代碼進行了單元測試嗎？
4、你是否逐步通過了每一條編碼路徑以觀察數據流？
5、你是否逐步通過了匯編語言層次上的所有關鍵代碼？
6、是否清理過了任何代碼？如果是，修改處經過徹底測試了嗎？
7、文檔是否指出了使用你的代碼有危險之處？
8、程序維護人員是否能夠理解你的代碼？
每當實現了一個函數或子系統之時 1、是否用斷言證實了函數參數的有效性？
2、代碼中是否有未定義的或者無意義的代碼？
3、代碼能否創建未定義的數據？
4、有沒有難以理解的斷言？對它們作解釋了沒有？
5、你在代碼中是否作過任何假設？
6、是否使用斷言警告可能出現的非常情況？
7、是否作過防御性程序設計？代碼是否隱藏了錯誤？
8、是否用第二個算法來驗證第一個算法？
9、是否有可用于確認代碼或數據的啟動（startup）檢查?
10、代碼是否包含了隨機行為？能消除這些行為嗎？
11、你的代碼若產生了無用信息，你是否在DEBUG代碼中也把它們置為無用信息？
12、代碼中是否有稀奇古怪的行為？
13、若代碼是子系統的一部分，那么你是否建立了一個子系統測試？
14、在你的設計和代碼中是否有任意情況？
15、即使程序員不感到需要，你也作完整性檢查嗎？
16、你是否因為排錯程序太大或太慢，而將有價值的DEBUG測試拋置一邊？
17、是否使用了不可移植的數據類型？
18、代碼中是否有變量或表達式產生上溢或下溢？
19、是否準確地實現了你的設計？還是非常近似地實現了你的設計？
20、代碼是否不止一次地解同一個問題？
21、是否企圖消除代碼中的每一個if語句？
22、是否用過嵌套？：運算符？
23、是否已將專用代碼孤立出來？
24、是否用到了有風險的語言慣用語？
25、是否不必要地將不同類型的運算符混用？
26、是否調用了返回錯誤的函數？你能消除這種調用嗎？
27、是否引用了尚未分配的存儲空間？
28、是否引用已經釋放了的存儲空間？
29、是否不必要地多用了輸出緩沖存儲？
30、是否向靜態或全局緩沖區傳送了數據？
31、你的函數是否依賴于另一個函數的內部細節？
32、是否使用了怪異的或有疑問的C慣用語？
33、在代碼中是否有擠在一行的毛病？
34、代碼有不必要的靈活性嗎？你能消除它們嗎？
35、你的代碼是經過多次“試著”求解的結果嗎？
36、函數是否小并容易測試？
每當設計了一個函數或子系統后 1、此特征是否符合產品的市場策略？
2、錯誤代碼是否作為正常返回值的特殊情況而隱藏起來？
3、是否評審了你的界面，它能保證難于出現誤操作嗎？
4、是否具有多用途且面面俱到的函數？
5、你是否有太靈活的（空空洞洞的）函數參數？
6、當你的函數不再需要時，它是否返回一個錯誤條件？
7、在調用點你的函數是出易讀？
8、你的函數是否有布爾量輸入？
修改錯誤之時
1、錯誤無法消失，是否能找到錯誤的根源？
2、是修改了錯誤的真正根源，還是僅僅修改了錯誤的癥狀？