摘要：下面就為大家帶來個人認為的常見的爛注釋風格。
相信作為程式員的大家，隻要寫代碼，就會自己寫及看到别人寫的代碼注釋。是以，我們往往會遇到“百花齊放，百家争鳴”般的注釋。程式員最讨厭的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行寫到代碼中，會對代碼的閱讀産生多大的影響呀？但不寫，又會對後面的維護帶來問題。