一直以來我沒有見過任何科學研究證明了這一點，但在軟件領域，它就像一個教條或一個共同的信念。由于它的存在，將軟件寫得易于閱讀、關注代碼的可讀型都是很重要的。通過一些技術的輔助程序員可以實現這些要求，這些技術其中之一就是寫代碼注釋。
免責聲明：我所說的“避免代碼注釋”并不意味著我不寫注釋，這意味著，我盡可能避免寫代碼注釋，但當我覺得值得寫時我還是寫的。
“相比寫軟件我們花了更多的時間在閱讀軟件上”，一直以來我沒有見過任何科學研究證明了這一點，但在軟件領域，它就像一個教條或一個共同的信念。由于它的存在，將軟件寫得易于閱讀、關注代碼的可讀型都是很重要的。通過一些技術的輔助程序員可以實現這些要求，這些技術其中之一就是寫代碼注釋。
當談論起代碼注釋的時候，有關的辯論總無休止。我們應該用注釋來說明我們代碼的作用嗎，我們應該將重點放在代碼的表達性而不需要注釋來輔助閱讀嗎？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);
}
公眾號
事業單位
當前位置：
公考類
招聘類
各類考試
