編寫程序時供參考的《編碼檢查表》
這份《編碼檢查表》，摘自《編程精粹——Microsoft編寫優質無錯C程序的秘訣》（[美] Steve Maguire著），是微軟公司的出版物。雖然講的是C/C++程序代碼的編寫原則，但基本思維是其它編程語言也應該參考的，特貢獻給各位參考。編碼檢查表
一般問題
你是否為程序建立了DEBUG版本？
你是否將發現的錯誤及時改正了？
你是否堅持徹底測試代碼，即使耽誤了進度也在所不惜？
你是否依靠測試組為你測試代碼？
你是否知道編碼的優先順序？
你的編譯程序是否有可選的各種警告？
關於將更改併到主程序
你是否將編譯程序的警告（包括可選的）都處理了？
你的代碼是否未用Lint？
你的代碼進行了單元測試嗎？
你是否逐步通過了每一條編碼路徑以觀察數據流？
你是否逐步通過了彙編語言層次上的所有關鍵代碼？
是否清理過了任何代碼？如果是，修改處經過徹底測試了嗎？
文檔是否指出了使用你的代碼有危險之處？
程序維護人員是否能夠理解你的代碼？
每當實現了一個函數或子系統之時
是否用斷言證實了函數參數的有效性？
代碼中是否有未定義的數據？
有沒有難以理解的斷言？對它們作解釋了沒有？
你在代碼中是否作過任何假設？
是否使用斷言警告可能出現的非常情況？
是否作過防禦性程序設計？代碼是否隱藏了錯誤？
是否用第二個算法來驗證第一個算法？
是否有可用於確認代碼或數據的啓動(startup)檢查？
代碼是否包含了隨機行為？能消除這些行爲嗎？
你的代碼若產生了無用信息，你是否在DEBUG代碼中也把它們置為無用信息？
代碼中是否有稀奇古怪的行爲？
若代碼是子系統的一部分，那麽你是否建立了一個子系統測試？
在你的設計和代碼中是否有任意情況？
即使程序員不感到需要，你也作完整性檢查嗎？
你是否因爲排錯程序太大或太慢，而將有價值的DEBUG測試抛置一邊？
是否使用了不可移植的數據類型？
代碼中是否有變量或表達式產生上溢或下溢？
是否準確地實現了你的設計？還是非常近似地實現了你的設計？
代碼是否不止一次地解同一個問題？
是否企圖消除代碼中的每一個if語句？
是否用過嵌套?:運算符？
是否已將專用代碼孤立出來？
是否用到了有風險的語言慣用語？
是否不必要地將不同類型的運算符混用？
是否調用了返回錯誤的函數？你能消除這種調用嗎？
是否引用了尚未分配的存儲空間？
是否引用已經釋放了的存儲空間？
是否不必要地多用了輸出緩衝存儲？
是否向靜態或全局緩衝區傳送了數據？
你的函數是否依賴於另一個函數的内部細節？
是否使用了怪異的或有疑問的C慣用語？
在代碼中是否有擠在一行的毛病？
代碼有不必要的靈活性嗎？你能消除它們嗎？
你的代碼是經過多次“試著”求解的結果嗎？
函數是否小並容易測試？
每當設計了一個函數或子系統後
此特徵是否符合產品的市場策略？
錯誤代碼是否作爲正常返回值得特殊情況而隱藏起來？
是否評審了你的界面，它能保證難於出現誤操作嗎？
是否具有多用途且面面俱到的函數？
你是否有太靈活的（空空洞洞）函數參數？
當你的函數不再需要時，它是否返回一個錯誤條件？
在調用點你的函數是否易讀？
你的函數是否有布爾量輸入？
修改錯誤之時
錯誤無法消失，是否能找到錯誤的根源？
是修改了錯誤的真正根源，還是僅僅修改了錯誤的症狀？
[ 本帖最后由 TonyDeng 于 2011-7-27 12:40 编辑 ]
