原文地址：http://sunxiunan.com/?p=1929
1) 是否有語法錯誤，編譯錯誤，編譯警告。
做法：下載最新代碼，將編譯警告級別提升到最高，檢查output信息。
2）是否符合需求，完成requirement文檔要求的內容，不能多，也不能少。
注意：即使發現有問題代碼，如果與需求關聯不大，不要涉及。
應該讓每次enhancement和bug fix最簡潔，牽涉範圍最小，影響到組件最少。
3）是否符合編碼規範：
a) 注意等號前後，操作符前後的空格和tab，行尾不要有多餘空白字符
b) 注意命名規範，少用縮寫形式，少用2/3/ex這種增強版
c) 對於循環局部變量，注意少用I,j在較長代碼中（三四行OK）
d) ..
4）代碼美感
a) 不能有嵌套的if-for-switch-while出現
b) 不能有非常複雜的條件判斷表達式（用於if-while之類）
c) 足夠的註釋，對於複雜操作，對於條件判斷，可以註釋。儘量讓代碼自己說明自己。
d) 如果代碼不能在短時間內理解，或者稍作解釋就可以理解，應該看看能否有更簡潔的方式
e) 函數不要過長，不能超過一屏顯示，最多不應該超過2-3屏。
f）經常問自己是否有更好的辦法，更簡潔明瞭的代碼形勢
g) 一個函數只做一件事，如果需要多個功能，再寫一個
h) 少用boolean 作爲參數切換功能，用withXXXcase, usingXXXcondition函數名字來自說明。道理同g)
i) 少用重載功能，沒必要類似函數用一個名字，既然有不同函數實現，那麼應該有不同條件描述，可參考h)的命名
j) 抽象層次不要過多，不要過早和過多考慮設計模式/抽象/抽取通用功能這些事情，這些在代碼重構階段可以修改調整。
5）邏輯
a) 參考上一條4)，基本上有足夠美感的代碼，邏輯上問題都不大
6）雜項
a) 性能的關注應該基於profiling data，而不是猜測
b) 代碼的正確與否，不是基於猜測而是基於test case
c) 擴展性不需要考慮過多，有一點點就好
d) 時時問自己，這個函數/變量/邏輯判斷/.. 有沒有必要，是不是可以刪掉的
e) 時時問自己，如果不用手動測試，自動化測試自己這段代碼，可以不可以？如何實現？(MEF or 數據界面分離… )可否通過腳本、工具自動化某些流程？