在我們關于高效代碼審查的博文中，我們建議使用一個檢查清單。在代碼審查中，檢查清單是一個非常好的工具——它們保證了審查可以在你的團隊中始終如一的進行。它們也是一種保證常見問題能夠被發現并被解決的便利方式。
軟件工程學院的研究表明，程序員們會犯15-20種常見的錯誤。所以，通過把這些錯誤加入到檢查清單當中，你可以確保不論什么時候，只要這些錯誤發生了，你就能發現它們，并且可以幫助你杜絕這些錯誤。
為了幫助你開始創建一個清單，這里列出了一些典型的內容：代碼審查清單。
常規項####
- 代碼能夠工作么？它有沒有實現預期的功能，邏輯是否正確等。
- 所有的代碼是否簡單易懂？
- 代碼符合你所遵循的編程規范么？這通常包括大括號的位置，變量名和函數名，行的長度，縮進，格式和注釋。
- 是否存在多余的或是重復的代碼？
- 代碼是否盡可能的模塊化了？
- 是否有可以被替換的全局變量？
- 是否有被注釋掉的代碼？
- 循環是否設置了長度和正確的終止條件？
- 是否有可以被庫函數替代的代碼？
- 是否有可以刪除的日志或調試代碼？
安全####
- 所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和范圍）并且進行了編碼？
- 在哪里使用了第三方工具，返回的錯誤是否被捕獲？
- 輸出的值是否進行了檢查并且編碼？
- 無效的參數值是否能夠處理？
文檔####
- 是否有注釋，并且描述了代碼的意圖？
- 所有的函數都有注釋嗎？
- 對非常規行為和邊界情況處理是否有描述？
- 第三方庫的使用和函數是否有文檔？
- 數據結構和計量單位是否進行了解釋？
- 是否有未完成的代碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’？
測試####
- 代碼是否可以測試？比如，不要添加太多的或是隱藏的依賴關系，不能夠初始化對象，測試框架可以使用方法等。
- 是否存在測試，它們是否可以被理解？比如，至少達到你滿意的代碼覆蓋(code coverage)。
- 單元測試是否真正的測試了代碼是否可以完成預期的功能？
- 是否檢查了數組的“越界“錯誤？
- 是否有可以被已經存在的API所替代的測試代碼？
優化你的清單####
把使用清單作為你的起點，針對特定的使用案例，你需要對其進行優化。一個比較棒的方式就是讓你的團隊記錄下那些在代碼審查過程中臨時發現的問題，有了這些數據，你就能夠確定你的團隊常犯的錯誤，然后你就可以量身定制一個審查清單。確保你刪除了那些沒有出現過的錯誤。（你也可以保留那些出現概率很小，但是非常關鍵的項目，比如安全相關的問題）。
得到認可并且保持更新
基本規則是，清單上的任何條目都必須明確，而且，如果可能的話，對于一些條目你可以對其進行二元判定。這樣可以防止判斷的不一致。和你的團隊分享這份清單并且讓他們認同你清單的內容是個好主意。同樣的，要定期檢查你的清單，以確保各條目仍然是有意義的。
有了一個好的清單，可以提高你在代碼審查過程中發現的缺陷個數。這可以幫助你提高代碼標準，避免質量參差不齊的代碼審查。
