武林網(www.vevb.com)文章簡介：一直以來我沒有見過任何科學研究證明了這一點，但在軟件領域，它就像一個教條或一個共同的信念。由於它的存在，將軟件寫得易於閱讀、關注代碼的可讀型都是很重要的。通過一些技術的輔助程序員可以實現這些要求，這些技術其中之一就是寫代碼註釋。
免責聲明：我所說的避免代碼註釋並不意味著我不寫註釋，這意味著，我盡可能避免寫代碼註釋，但當我覺得值得寫時我還是寫的。
相比寫軟件我們花了更多的時間在閱讀軟件上，一直以來我沒有見過任何科學研究證明了這一點，但在軟件領域，它就像一個教條或一個共同的信念。由於它的存在，將軟件寫得易於閱讀、關注代碼的可讀型都是很重要的。通過一些技術的輔助程序員可以實現這些要求，這些技術其中之一就是寫代碼註釋。
當談論起代碼註釋的時候，有關的辯論總無休止。我們應該用註釋來說明我們代碼的作用嗎，我們應該將重點放在代碼的表達性而不需要註釋來輔助閱讀嗎？ Joe Kunk為這爭論寫了一篇博客-應不應該寫註釋。有那些人說文檔完備的代碼被認為是好代碼，還有些人說應該避免註釋，因為註釋通常被用來解釋/隱藏不好的代碼。
在我看來，在書籍的影響下，為確保代碼整潔便於重構，我們應該避免寫註釋，除非我們有一個好的寫註釋的理由（例如數學算法）或因為公司要求或流程我們有義務這樣做。下面是我關於註釋的五點憂慮。
我認為代碼註釋起到反作用的地方1.註釋往往鼓勵壞的代碼註釋的代碼是好代碼有這樣一個說法，所以人們常常在代碼中添加註釋以代碼漂亮。如果我們為了解釋代碼而添加註釋這就像是一個信號：也許我們正在編寫糟糕的代碼。當我們要寫一條註釋是，我們應該想是否能夠通過清理代碼使它更有可讀性呢。
2. 我們將花費更多的時間來編寫和維護註釋通常是代碼的第二個版本。當我們為一個函數寫註釋時我們實際在重複自己。我們違背了DRY（不要重複自己）原則。我們正在花費更多的時間且增加了複雜性。需求如果變了代碼也要跟著變，如果我們寫了註釋也要隨之更改。所以為多花費的一倍時間做出改變吧。我們可以利用這段時間來提高我們的代碼或開發新的功能。
3. 註釋是不可測試和驗證的當我們修改代碼的時候我們藉助諸如編譯器、IDE及單元測試工具來輔助，註釋沒有，沒有類似工具。你無法依靠工具或單元測試來確保它們的使用位置、日期標註等是正確的。一旦你寫了一條註釋，因為它是不可測試的無法關注它的準確性，一旦出錯便會無法察覺的保留下來。
4. 與代碼相比註釋是不可靠的通常當註釋和代碼脫離它就變得與沒有多大意義了。如果程序員讀到它就可能被誤導。即使沒有誤導也需要通過閱讀源碼來搞清到底做了什麼。一個實際的例子，如果我們的老闆需要我們做一個修改，我們應該看註釋還是代碼呢？當然我們會看代碼。
5. 註釋佔用了不少屏幕空間一些註釋方法（像下面的）佔了很多行，當你想查看更多代碼時這便成了一個問題。
/**
*
* @param title The title of the CD
* @param author The author of the CD
* @param tracks The number of tracks on the CD
* @param durationInMinutes The duration of the CD in minutes
*/
public void addCD(String title, String author,
int tracks, int durationInMinutes) {
CD cd = new CD();
cd.title = title;
cd.author = author;
cd.tracks = tracks;
cd.duration = duration;
cdList.add(cd);
}