註釋的恰當用法是彌補我們在用程式碼無法表達意圖是遭遇的失敗。注意，我用來“失敗“一次。我是說真的。我們總無法找到不用註釋就能表達自我的方法，所以總要有註釋，這並不值得慶賀。
程式設計師應當負責將註釋保持在可維護、有關聯、精確的高度。我同意這一說法。但我更主張把力氣用著寫清楚程式碼上，直接保證無須編寫註釋。不準確的註釋要比沒註釋壞的多。它們滿口胡言。它們預期的東西永不能實現。它們設定了無需也不應再遵循的舊規則。

1.註釋不能美化糟糕的程式碼:

寫註釋的常見動機之一是糟糕的程式碼的存在。我們編寫一個模組，發現它令人困擾、亂七八糟，我們知道，它爛透了。我們告訴自己：”喔，最好寫點註釋“ 不！最好是吧程式碼弄乾淨！
帶有少量註釋的整潔而有表達力的程式碼，要比帶有大量註釋的零散而複雜的程式碼像樣得多。與其花時間編寫解釋你搞出的糟糕的程式碼的註釋，不如花時間清潔那段糟糕的程式碼。

2.警示:

用於警告其他程式設計師會出現某種後果的註釋也是有用的。例如，下面的註釋解釋了為什麼要關閉某個特定的測試用例:

// Don't run unless you have some time to kill
public void testWithReallyBigFile()
{
    writeLinesToFile(100000000);
    response.setBody(testFile);
    String responseString = output.toString();
    assertSubString("Content-Length: 10000000",responseString);
    assertTrue(bytesSent>100000000
 
);
}

3.廢話註釋:

有時，你會看到純然是廢話的註釋。它們對於顯然之事喋喋不休，毫無新意。例如:

/**
* Default constructor.
* /
protected AnnualDateRule() {
}

又或者:

/** The day of the month. */
      private int dayOfMonth;

這類註釋廢話連篇，我們都學會了視而不見，讀程式碼時，眼光不會停留在它們上面。最終當代碼修改之後，這類註釋就變成了謊言一堆。
用整理程式碼的決心替代創造廢話的衝動吧。你會發現自己成為更優秀、更快樂的程式設計師。

4.括號後面的註釋:

有時，程式設計師會在括號後面放置特殊的註釋，程式碼如下:

儘管這對於含有深度巢狀結構的長函式可能有意義，但只會給我們更願意編寫的短小、封裝的函式帶來混亂，如果你發現自己想標記右括號，其實更應該做的是縮短函式。