不出意外，Linus又開噴了，這次的激情開麥，源自一部分沒有做注釋的合并請求：Linux6.3內核收到了一部分合并請求，但這部分合并完全沒有注釋。
如果你懶得解釋為什么存在一個合并，那這個合并從本質上來說就是錯誤的垃圾，這是每個開發(fā)者都應牢記于心的規(guī)則。我重復一遍：如果你不能解釋清楚這個合并請求，那就不要做，就是這么簡單?！狶inus Torvalds
讓Linus如此生氣的代碼注釋，到底有啥用？
注釋不僅展現了代碼背后的邏輯，讓我們在后期維護時能更容易閱讀、理解代碼，還能將授權許可、版權信息編寫進去。此外，注釋也有提示作用，如標記為FIXME或TODO的注釋往往表示待定的工作等等。
總之，代碼注釋告訴了我們?yōu)槭裁磿戇@樣的代碼。對Linus來說，收到的合并請求缺乏注釋，因為沒有合理的解釋，代碼不僅變得毫無意義，還會變得更難讀、難維護。所以代碼注釋很重要，編寫合理的代碼注釋更重要。
編寫注釋，快看這三不要！
1.不要花大力氣編寫注釋，解釋代碼的每一個細節(jié)！
過多的注釋會讓源文件變得非常混亂，不僅會降低代碼的可讀性，還難以維護。（這種寫大量注釋的行為，也很難不讓Linus發(fā)火。）
2.不要留不恰當的注釋！
很多人會通過注釋保存代碼演變的歷史記錄，但這往往是無用功。一個熱知識：版本控制系統可以保存歷史記錄。還有一些過時的、被廢棄的、不正確的注釋，一經發(fā)現就需要盡快更新或刪除，不能再讓這些廢棄注釋誤導我們了！
3.不要猶豫！看到注釋掉的代碼，請直接刪掉它！
對于那些不再使用的舊代碼，大家可能下意識會直接注釋掉，但直接干脆利落刪除掉這些舊代碼會更簡潔。畢竟后期維護的時候，大家面對這些注釋掉的代碼只會敬而遠之。
重構吧！
通過重構那些爛代碼，可以擺脫不必要的注釋：
-
命名：比如將變量
i重命名為numGoals，能明確意圖。對于變量、方法以及類，我們都可以這樣做； - 結構：如果某一段代碼沒有注釋就無法理解，可以嘗試更改代碼結構；
- 子表達式：將一個復雜的表達式拆分為多個子表達式，可以幫助大家更好地理解代碼；
- 斷言：當我們遇到“當某個條件為真時，某段代碼才能正常運行”的情況時，可以引入斷言標明假設。
這樣才能使注釋更簡潔、易看。
如何編寫好的代碼注釋？
以下幾個注釋模式送給大家：文章來源：http://www.zghlxwxcb.cn/news/detail-406327.html
- 文檔注釋模式：記錄接口，而不是解釋代碼本身。
- 腳注注釋模式：主要用于描述為什么采用特定方法，短小精悍。通常在無法從代碼中推斷出此類信息的情況中使用。
-
警告注釋模式：警告開發(fā)人員注意某些特殊需求的注釋，如：以超級管理員的身份調用函數。警告可能涉及安全或設計缺陷，注釋可能包括
TODO或FIXME。 - 簽名注釋模式：注釋中加上開發(fā)人員的首字母縮寫。在團隊中，我們可以更快速地找到相應人員討論。
- 編織代碼模式：代碼和文檔結合在一起。需要首先編寫文檔，然后對該文檔進行編碼。
在Linus看來，寫代碼非常重要，寫好的代碼更重要。注釋、命名、版式等代碼規(guī)范檢驗的正是程序員最重要的基本功，如果基礎不牢，必定地動山搖。文章來源地址http://www.zghlxwxcb.cn/news/detail-406327.html
到了這里，關于Linux之父：連你自己都懶得解釋，那這就是一堆垃圾！的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
