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