別給糟糕的代碼加註釋， ---重新寫
如果編程語言足夠有表達力，或我們長於用這些語言來表達意圖，就不那麼需要註釋。註釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失敗。
編寫優美的代碼，儘量減少註釋量
- 註釋不能美化糟糕的代碼
編寫帶有少量（或沒有）註釋的整潔而有表達力的代碼
- 用代碼來闡述
不要用註釋來理解代碼，讓代碼更具表達力
- 好註釋
有些註釋是必須的，也是有利的。
3.1 法律信息
3.2 提供信息的註釋
3.3 對意圖的解釋
3.4 闡釋 把某些晦澀難明的參數或返回值的意義翻譯爲某種可讀形式。
3.5 警示 用於警告其他程序員會出現某種後果
3.6 TODO註釋 用//TODO的形式在源代碼中放置要做的工作列表。
3.7 放大 註釋可以用來放大某種看來不合理之物的重要性。
3.8 公共API中的Javadoc /* /
- 壞代碼
通常壞註釋都是糟糕的代碼的支撐或接口，或對錯誤決策的修正
4.1 喃喃自語 如果只是因爲你覺得應該或者因爲過程需要就添加註釋
4.2 多餘的註釋
4.3 誤導性註釋 註釋不夠準確
4.4 循規式註釋 並不是每個函數都要Javadoc 每個變量都要註釋
4.5 日誌式註釋 每次編輯代碼是在模塊開始出添加一條註釋。在現在有版本控制系統時，會讓模塊變得凌亂不堪 目前用的少了。
4.6 廢話註釋
4.7 可怕的廢話 Javadoc的廢話
4.8 能用函數或變量時就別用註釋
4.9 位置標記
4.10 括號後面的註釋 分離函數
4.11 歸屬與署名
4.12 註釋掉的代碼 直接把代碼註釋掉是討厭的做法。直接刪掉。不然後來人不敢刪除
4.13 HTML註釋 源代碼中加入html註釋影響理解
4.14 非本地信息 注意註釋要離它的代碼最近
4.15 信息過多 別在註釋中添加有趣的歷史性話題或者無關的細節描述
4.16 不明顯的聯繫 註釋與代碼之間聯繫應該顯而易見
4.17 函數頭 寫好的函數名的重要性
4.18 非公共代碼中的Javadoc 如果函數不當作公共方法類就不要寫Javadoc
