避免代碼注釋的五大理由
代碼注釋的作用一直以來都被程序員們廣泛討論。很多人認為注釋不是必要的，寫注釋那是因為代碼可讀性太差了。原文作者Paulo Ortins發表了博文《5 reasons to avoid code comments》，以下為譯文：
通常，我們閱讀軟件比編寫軟件花費的時間要更多。雖然我從未見過任何科學研究能夠證明這一點，但是在軟件領域，它就好比一個教條或者信念如此的根深蒂固。 正因為編寫軟件要比閱讀軟件要容易，因此代碼的可讀性而顯得尤為重要。程序員可以通過一些技術來實現它，其中一點就包括代碼注釋。
關于代碼注釋的文章，網絡上有很多討論。我們應該使用注釋來解釋代碼嗎？還是應該注重編寫表達式代碼而無需閱讀注釋？Joe Kunk曾發表過一篇文章《To Comment or Not to Comment》其中有段內容是說所謂的好代碼是指我們應該避免注釋，因為注釋通常是用來解釋/隱藏惡意代碼。
下面就來討論下避免寫代碼注釋的五大理由：
1. 程序員更加傾向于鼓勵”壞“代碼。
有一種說法，有代碼注釋的就是好代碼，因此，程序員經常在代碼邊上寫注釋，使其看起來更加出色。如果我們把代碼注釋當做一種信號，那么也許我們正在編寫壞代碼。每當我們寫注釋時應該思考如何使代碼看清來更加潔凈。
2. 花費更多時間來編寫和維護
如果注釋沒有跟隨代碼的變化而變化，即使是正確的注釋也沒有用。注釋通常作為代碼的第二個版本。當為某個函數寫注釋時我們需要不斷的重復自己，這就違反了 DRY(Don’t Repeat Yourself) 原則。花費時間來增加復雜性，軟件需求改變了，代碼也隨之跟著變化。如果我們寫注釋，這就意味著必須去維護注釋。因此，除非是很必須要，否則我們應該拒絕 在注釋上花費雙倍時間，相反我們可以利用這些時間來提高代碼的質量或開發新的特性。
3. 注釋不是測試/驗證
修改代碼可以依賴工具，比如使用編譯器、IDEs及單元測試；而注釋卻不能。注釋沒有這些工具，你無法依賴工具或者單元測試在正確的地方或者過期后來確保 它們的正確性。一旦你寫了注釋，沒有測試模塊來驗證它的正確性，一旦這個注釋失敗了，那么它就永遠的失敗了。
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);
- }
