摘要：下面就為大家帶來個人認為的常見的爛注釋風格，
相信作為程式員的大家，只要寫代碼，就會自己寫及看到別人寫的代碼注釋，所以，我們往往會遇到“百花齊放，百家爭鳴”般的注釋，程式員最討厭的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行寫到代碼中，會對代碼的閱讀產生多大的影響呀？但不寫，又會對后面的維護帶來問題，
本文分享自華為云社區《我的注釋我做主》，原文作者：周大仙人 ，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/248083.html
標籤：java