1. 註釋
不恰當的信息 註釋只應該描述有關代碼和設計的技術性信息。
廢棄的註釋 過時、無關、不正確的註釋
冗餘註釋 註釋描述的是某種充分自我表述了得東西。
糟糕的註釋 值得編寫的註釋，也值得好好寫
註釋掉的代碼 沒人知道他存在的意義。忽視掉的代碼就刪掉。 版本控制器會記住他的。
2. 環境
需要多步才能實現的構建 構建系統應該是單步的小操作。
需要多步才能做到的測試 應當能夠發出單個指令就可以運行全部單元測試。
3. 函數
過多的參數 函數的參數量應該少。
輸出參數 輸出參數違反直覺
標識函數 布爾值參數大聲宣告函數做了不止一件事。它令人迷惑，應該消滅掉
死函數 永不被調用的方法應該丟棄
4. 一般性問題
一個源文件中存在多種語言
源文件中包括且只包括一種語言。當非要使用時，應儘量減少額外語言的數量和範圍。
明顯的行爲未被實現
遵循”最小驚異原則”，*函數或類應該實現其他程序員有理由期待的行爲。
不正確的邊界行爲
代碼應該有正確行爲。別依賴直覺，追索各種邊界條件，並編寫測試。
忽視安全
關閉失敗測試，告訴自己過後再處理很不明智
重複
模板方式模式和策略模式很好的消除重複。應儘可能找到並消除重複
在錯誤的抽象層級上的代碼
創建分離較高層級一般性概念與較低層級細節概念的抽象模型，很重要。
所有較低層級概念放在派生類中，所有較高層級概念放在基類中。
基類依賴於派生類
將概念分解到基類和派生類的最普遍的原因是較高層級基類可以不依賴於較低層級派生類概念
信息過多
設計良好的模塊有着非常小的接口，讓你事半功倍，反之就事倍功半了
學會限制類或模塊中暴露的接口數量。類中的方法越少越好。函數知道的變量越少越好。類擁有的實體變量越少越好。儘量保持接口緊湊，通過限制信息來控制耦合度。
隱藏你的數據，工具函數，常量和臨時變量。不要創建大量方法，或大量實體變量的類
死代碼
即不執行的代碼。不會發生的if語句體中。不會發生的catch中
垂直隔離
變量和函數應該在靠近被使用的地方定義
前後不一致
命名前後一致，堅決貫徹，就能讓代碼更易於閱讀和理解
混淆視聽
去掉沒有使用的信息。保持源文件整潔，良好地組織，不被搞亂。
特性依戀
類的方法只應對其所屬類中的變量和函數感興趣，不該垂青其他類中的變量和函數。
人爲耦合
不相互依賴的東西不該耦合。人爲耦合是指兩個沒有直接目的的之間模塊的耦合。
選擇算子參數
函數調用結尾遇到一個false參數
代碼要儘可能具有表達力
位置錯誤的權責
在哪裏放代碼?
需要靜態函數時，確保沒機會打算讓他有多態行爲
使用解釋性變量
將計算過程打散成在用有意義的單詞命名的變量中放置的中間值。
函數名稱應該表達其行爲
理解算法
獲得這種知識和理解的最好途徑，往往是重構函數，得到某種整潔而足具表達力、清楚呈示如何工作的東西
把邏輯依賴改爲物理依賴
依賴者模塊不應對被依賴着模塊有假定（邏輯依賴），他應當明確詢問後者全部信息。
用多態代替if/eles 或Switch/Case
團隊成員都應遵循這些約定，
用命名常量替代魔術數
魔術數 泛指任何不能自我描述的符號
準確
堅守結構甚於約定的設計決策。
封裝條件
避免否定性條件
否定式要比肯定式難明白一些。儘可能將條件表示爲肯定形式
函數只該做一件事
讓時序耦合變得可見
別隨意
構建代碼需要理由，而且理由應於代碼結構相契合
邊界條件難以追蹤，把邊界條件的代碼集中到一處，不要散落於代碼中。
函數應該只在一個抽象層級上
在較高層級放置可配置數據
避免傳遞瀏覽
確保模塊只瞭解其協作者，不瞭解整個系統的瀏覽圖。讓直接協助者提供所需的全部服務。
5. Java
通過使用通配符避免過長的導入清單
不要使用繼承常量
常量Vs枚舉 多使用枚舉
6. 名稱
採用描述性名稱
名稱應與抽象層級相符
儘可能使用標準命名法
無歧義的名稱
爲較大作用範圍選用較長名稱 名稱的長度應於作用範圍的廣泛度相關
避免編碼 不應在名稱中包含類型或作用範圍信息
名稱應該說明副作用 名稱應該說明函數、變量或類的一切信息
7. 測試
測試不足
使用覆蓋率工具
別略過小測試
被忽略的測試就是對不確定事物的疑問
測試邊界條件
全面測試相近的缺陷
測試失敗的模式有啓發性
測試覆蓋率的模式有啓發性
測試應該快速