• 註釋：
  • 不恰當的信息：註釋只應該描述有關代碼和設計的技術性信息。
  • 廢棄的註釋：過時、無關或不正確的註釋就是廢棄的註釋。
  • 冗余註釋：註釋應該談及代碼自身沒提到的東西
  • 糟糕的註釋：值得編寫的註釋，也值得好好寫。
  • 註釋掉的代碼
• 環境：
  • 需要多步才能實現的構建：構建系統應該是單步的小操作。
  • 需要多步才能做到的測試：應當能夠發出單個指令就可以運行全部單元測試。能夠運行全部測試是如此基礎和重要，應該快速、輕易和直截了當地做到。
• 函數
  • 過多的參數，沒參最好
  • 輸出參數：輸出參數就違反直覺。如果函數非要修改什麽東西的狀態不可，就修改它所在對象的狀態好了。
  • 標識參數：布爾值參數大聲宣告函數做了不止一件事。
  • 死函數：永不被調用的方法應該丟棄。別害怕刪除函數。
• 一般性問題：
  • 一個源文件中存在多種語言：理想的源文件包括且只包括一種語言，應該盡力減少源文件中額外語言的數量和範圍。
  • 明顯的行為未被實現：最小驚異原則--函數或類應該實現其他程序員有理由期待的行為。
  • 不正確的邊界行為：別依賴直覺。追索每種邊界條件，並編寫測試。
  • 忽視安全：關閉失敗測試、告訴自己過後再處理，這和假裝刷信用卡不用還錢一樣壞。
  • 重復：核心原則。每次看到重復代碼，都代表遺漏了抽象。
  • 在錯誤的抽象層級上的代碼：只與細節實現有關的常量、變量或工具函數不應該在基類中出現。
  • 基類依賴於派生類：例外情況是派生類數量嚴格固定。
  • 信息過多：設計良好的模塊有著非常小的接口，讓你能事半功倍。設計良好的接口並不提供許多需要依靠的函數，所以耦合度也較低。設計低劣的接口提供大量你必須調用的的函數，耦合度較高。隱藏你的數據。隱藏你的工具函數。隱藏你的常量和你的臨時變量。不要創建擁有大量方法或大量實體變量的類。不要為子類創建大量受保護變量和函數。盡量保持接口緊湊。通過限制信息來控制耦合度。
  • 死代碼：死代碼就是不執行的代碼。
  • 垂直分隔：變量和函數應該在靠近被使用的地方定義。
  • 前後不一致：從一而終，小心選擇約定，一旦選中，就小心持續遵循。
  • 混淆視聽：
  • 人為耦合：不互相依賴的東西不該耦合。
  • 特性依戀：類的方法只應對其所屬類中的變量和函數感興趣，不該垂青其他類中的變量和函數。
  • “選擇算子”參數：“選擇算子”參數只是一種避免把大函數切分為多個小函數的偷懶做法。選擇算子不一定是boolean類型，可能是枚舉元素、整數或任何一種用於選擇函數行為的參數。
  • 晦澀的意圖：代碼要盡可能具有表達力。
  • 位置錯誤的權責：軟件開發者做出的最重要決定之一就是在哪裏放代碼。（最小驚異原則）代碼應該放在讀者自然而然期待它所在的地方。
  • 不恰當的靜態方法：恰當的靜態方法不應在單個實體上操作。
  • 應當使用解釋性變量：讓程序可讀的最有力的方法之一就是將計算過程打散成在用有意義的單詞命名的變量中放置的中間值。
  • 函數名稱應該表達其行為：
  • 理解算法：“可以工作”是不行的，必須知道解決方案是正確的。
  • 應當把邏輯依賴改為物理依賴：依賴者模塊不應對被依賴者模塊有假定。
  • 應當用多態替代if/else或switch/case: 在使用if/else或switch/case前，先考慮使用多態。
  • 遵循標準約定：
  • 用命名常量替代魔術數：
  • 準確：
  • 結構甚於約定：堅守結構甚於約定的設計決策。命名約定很好，但卻次於強制性的結構。
  • 封裝條件：應該把解釋了條件意圖的函數抽離出來。
  • 避免否定性條件：
  • 函數只做一件事：
  • 不要掩蔽時序耦合：通過創建時序隊列暴露時序耦合。
  • 應當封裝邊界條件：
  • 函數應當只在一個抽象層級上：（拆分不同抽象層級是重構的最重要的功能之一）
  • 應當在較高層級放置可配置數據
  • 避免傳遞瀏覽：確保模塊只了解其直接協作者。
• Java
  • 通過使用通配符避免過長的導入清單：（這一項由IDE來實現）
  • 不要繼承常量：
  • 常量 VS. 枚舉 ：優先用枚舉
  • 采用描述性名稱：
  • 名稱應與抽象層級相符
  • 盡可能使用標準命名法：
  • 無歧義的名稱：
  • 避免編碼：不應在名稱中包括類型或作用範圍信息。
  • 名稱應該說明副作用：名稱應該說明函數、變量或類的一切信息。
• 測試：
  • 測試不足：
  • 使用覆蓋率工具：覆蓋率工具能匯報你測試策略中的缺口。
  • 別略過小測試
  • 被忽略的測試就是對不確定事物的疑問：需求不明確而不能確定某個行為細節，可以用註釋掉的測試或者用@Ignore標記的測試來表達我們對於需求的疑問。
  • 測試邊界條件
  • 全面測試相近的缺陷
  • 測試失敗的模式有啟發性
  • 測試覆蓋率的模式有啟發性
  • 測試應該快速

Clean Code 代碼檢查清單