每日分享最新，最流行的軟件開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支持，跪求關注，點贊，留言。
今天我想寫一下為什么注釋在軟件開發中如此重要以及如何改進它們。對我來說，好的源代碼最令人失望的事情是沒有對它進行足夠的注釋。封閉代碼會發生這種情況，其發生方式與開放源代碼相同。在最壞的情況下，這通常是最常見的，源代碼根本沒有注釋。尤其是在開源項目中，這是對社區閱讀你代碼的蔑視。但即使在內部軟件項目中，我也認為缺少評論是對同事的不良行為，應該避免。
當然，在這種情況下，我們都知道有趣的答案。“好的代碼不需要任何注釋”或“如果您不明白某些內容，請查看源代碼”。” 不寫評論是懶惰還是無知？不，相信很多開發者根本就不知道如何寫出好的注釋。出于這個原因，我想在這里解釋一個關于如何通過注釋真正改進源代碼的非常簡單的規則。
不要向我解釋是什么以及如何！
寫評論時你可能犯的最大錯誤是假設你必須解釋你在做什么。在這種情況下，您編寫注釋來解釋顯而易見的事情。
/**
* Class to build
*/
class {
....
}
只要類名或方法名不是絕對無意義的，名稱就應該說明類或方法的用途。所以請不要解釋說一個類構建一個對象或者一個方法返回一個對象。寫這樣的評論是浪費時間。順帶一提，那些不得不閱讀這種無用評論的人也是如此。
壞評論的第二個例子是解釋代碼是如何工作的。
/**
* Build the event and it.
*/
T build() {
....
event;
}
當然問答無用神秘代碼，您不應該假設閱讀您代碼的用戶是徹頭徹尾的白癡。您可以假設其他開發人員可以像您一樣編寫代碼。在方法或類的注釋中解釋軟件模式毫無意義。
所以現在我們已經看到什么是差評了。但是好的評論是什么樣的呢？
從為什么開始！
Simon Sinek 有一本很棒的書，書名是“從為什么開始：偉大的領導者如何激勵每個人采取行動”。這本書的核心信息是，你總是應該從解釋“為什么”開始。“什么”和“如何”通常會在稍后更詳細地解釋事情。對于軟件開發，“What”和“How”確實在代碼中，在很多情況下不需要注釋。
所以從“為什么”開始可以使源代碼注釋更有用——對你自己和其他人。從“為什么”開始會讓你思考你實際在做什么。所以回到我之前的例子，評論可能是這樣的：
/**
* When using in the , the may help
* to them in the way more .
*/
class {
....
}
因此，與其描述這個類是什么，不如回答你為什么發明它的問題。方法也是如此。如前所述，如果我想了解“如何”，那么我可以詳細閱讀源代碼。但是為什么類或方法存在呢？這就是評論的用途：
/**
* To the of an in the ,
* this the all taxes.
*/
float () {
....
event;
}
我不想詳細說明。很明顯問答無用神秘代碼，您對編寫類或方法的原因解釋得越好，就越有助于像您一樣的其他人理解您的代碼。因此，當您開始編寫下一個代碼時，請考慮您為什么要這樣做并將其注釋到您的類或方法標頭中。您會看到——您的同事和您的社區會喜歡它并且更愿意使用您的代碼。