摘要：下面就為大家帶來個人認為的常見的爛注釋風格。
相信作為程序員的大家，只要寫代碼，就會自己寫及看到別人寫的代碼注釋。所以，我們往往會遇到“百花齊放，百家爭鳴”般的注釋。程序員最討厭的10件事，0:寫注釋，1:別人不寫注釋。
作為一個老IT人，看了那么多年代碼，也就看了那么多年注釋。可以說，好代碼不一定有好注釋，但爛代碼基本和爛注釋共存。下面就為大家帶來個人認為的常見的爛注釋風格，希望能對大家在日后的工作中，帶來一絲絲的幫助。排名不分先后：
1. 注釋上帶聯系方式，TODO事項，問題單需求鏈接等。這種風格其實體現了工程師沒有意識去利用好現代的平台技術，還停留在90年代的編碼習慣。2020年了，git類軟件已經是軟件開發的首選代碼托管平台了，問題單需求鏈接和聯系方式的最佳位置應該是Git的提交日志上，TODO事項應該使用Git的issue管理。這種注釋看到就應該刪掉。例如以下兩種注釋
2. 注釋上帶有一部分設計內容。這些內容最大的問題是，沒人知道它是真是假，更沒人知道它是否完整，刪掉了吧，又有點可惜，萬一有點用呢？不刪吧，又看着不舒服。出現這種問題的最大原因是，團隊內沒有太好的地方承載這類文檔。2020年了，可以試試Github的pages平台。
3. 注釋上寫how，而不是why。這種大家都很清晰了，一致認為是不應該的。就不多說了，參考下面的例子
4. 對代碼的使用說明，例如方法如何調用，各項參數的說明，會拋出什么異常。例如以下的例子便是。有空寫這種注釋，還不如把測試用例寫好，通過用例來告訴用戶應該如何使用。
5. 代碼某種算法的特殊說明，這種比較有爭議性，嚴格來說，不算是爛注釋，但如果這種注釋沒有嚴格和代碼一起管理（例如改了代碼要同步改注釋），那么這種注釋就沒有好過有了。所以這雖然嚴格來說是一個管理原因，但2020年了，我更推薦把這種注釋寫到提交日志上。怎么說呢？我以Git的這段提交來說明這個問題，這段提交只設計到一個變量的非null判斷，很多人可能就直接提交了，有些人也會在代碼上加上注釋，闡述為什么要做這個非null判斷，但作者最終是選擇了在提交日志上闡述這段邏輯，而且足足寫了20行（刨去一些個人簽名，有效行數也很多），想象一下把這20行寫到代碼中，會對代碼的閱讀產生多大的影響呀？但不寫，又會對后面的維護帶來問題。
本文分享自華為雲社區《我的注釋我做主》，原文作者：周大仙人 。