你們猜猜，作爲程序員你們最討厭做的事是什麼？產品經理頻繁修改需求？不是。測試天天給你提交不可理喻的 bug ？也不是。接手別人交接的如火星文一樣的爛代碼？其實也不是。
其實我搞了一個文字遊戲，叫最討厭做的事，而不是最討厭的事，上述幾點，可能是你最討厭的事，但是你又可能不能不做。有一種令人髮指的討厭就是你討厭別人不去做，而自己又毫無察覺的在犯這個錯誤，卻心安理得，而程序員在什麼情況下，纔會這樣做呢？
程序員最討厭的四件事：
寫註釋、寫文檔、別人不寫註釋、別人不寫文檔。
不錯，今天我們就來談談程序員最討厭做的這件事：寫註釋。
程序員該不該寫註釋？
其實對於寫註釋這件事來說，還是有一定的爭議的，爭議其實不在於該不該寫註釋，而是在於不要過多的寫註釋，註釋多了，反而會讓你感覺整個代碼比較混亂不堪，影響視覺。而且有人爲什麼不太鼓勵大家過多的去寫註釋呢？因爲代碼即註釋，何爲代碼即註釋？代碼是具有自解釋功能的，高質量，命名規範的代碼，其實程序員應該一眼就能夠看懂這段代碼的功能作用是什麼？
所以，程序員到底該不該寫註釋？要我說：該，但是要注意分寸。
如何注意分寸？
優秀的程序員可以少寫註釋
優秀的程序員都是懶的。因爲懶，他纔會寫出各種各樣的工具來替自己幹活。因爲懶，他纔會想辦法避免去寫無聊重複的代碼——因此避免的代碼的冗餘，削減了代碼的維護成本，使重構變得更加容易。最終，這些由於懶惰激發出的動力而開發出的工具和最佳編程實踐方法提升了代碼和產品的質量。
上面我們說了，代碼即註釋。作爲一個優秀的程序員，他們懂得註釋不是用來翻譯程序代碼的，用代碼能說清楚的東西，就自然不用費腦子去寫註釋了，集中精力寫出最優雅、高質量的代碼纔是首要的。代碼是具有自解釋功能的，如果你寫的一個函數方法，命名非常規範，有一個好的方法名，裏面有很多可讀性很強的好的變量名，函數裏代碼又不是特別多，最多二三十行。別的程序員一眼就看懂了，知道這個函數的功能作用，這就是代碼的自解釋功能。這就告訴了我們命名的重要性，如果你能夠做到你的命名能完全、準確地描述所代表的事物和功能，這無疑提高整個項目代碼的可讀性，可以不寫註釋。
但是如果一個函數上百行代碼，甚至更多，還是需要寫一定的註釋的，甚至在一個重要的業務邏輯處理的地方，還是需要註明一些註釋的，畢竟時間久了，業務邏輯不熟悉了，看代碼確實有些費勁。在重要的業務邏輯代碼面前，還是需要一定的註釋。當然在命名的時候，再優秀的程序員可能也會遇到所命名的方法和函數，並不能準確代表所起的功能，這時寫註釋就很有必要了。記住：與人方便就是與己方便。
初級中等程序員還是得寫註釋
作爲一個入門，初級或者中等的程序員，在自己代碼質量不高的階段，時刻提醒自己養成一個好的寫註釋的習慣還是很有必要的。人不可能天生就是寫程序的料，也不可能一開始馬上就能夠寫出符合規範的高質量的代碼。所以，前期記住一定得寫註釋。
爲什麼很多程序員不願意接手別人寫的代碼，是因爲有一個問題就是必然存在的。每個人的編碼風格不一樣，命名方式和規範不一樣，這就是作爲初級和中等程序員最容易犯的錯誤。其實每個公司都應該有自己的編程規範纔可以。由於程序員代碼的個性化，就造就了代碼的多樣性。再加上沒有註釋，誰還願意看？
我感覺作爲一個程序員，都應該有一個強迫自己寫出高質量代碼的習慣，多讀讀系統源碼，別人的開源代碼，看看高手都是如何寫函數，做封裝的。慢慢的，一步一步的去改善自己的寫代碼的質量，慢慢的嘗試在感覺自己代碼質量比較高的時候，讓你同事看看，如果沒有註釋，他能看懂了，那這裏就少寫註釋，或者嘗試不寫註釋。
爲什麼談這個話題
談這個話題的原因
對，爲什麼談這個話題呢？因爲有很多程序員寫代碼總有一種非常非常不好的習慣，那就是一段代碼不用了，註釋掉，但是他心裏還總想着感覺這段代碼以後可能還會用。所以就留着，不刪掉，但大多數情況下，過幾天就忘了，結果代碼裏到處都是註釋，沒有一句是有用的。
接下來好了，接手的讀代碼的人也不敢刪，一直留着，留着，留着，留着……直到永遠。
你們大聲告訴我，你們是不是有這種習慣？是不是有這種心理？
註釋維護
我想說，註釋也是需要維護的。很多人都沒有意識到註釋維護的重要性。怎麼說呢？不寫註釋坑人，比不寫註釋更坑人的就是寫了註釋，功能變了，不修改註釋的人。比如：
今天是程序員小王寫了一個處理業務邏輯的功能方法，功能是炒菜。過了兩個月後，需求變了，人家客戶不喜歡喫炒菜，需要換成了煮菜了。這時程序員小陳就在炒菜的功能方法上直接修改了，把功能改成了煮菜。但是註釋上寫的還是炒菜。又過了兩個月，客戶需求又變了，客戶喫膩了煮的菜，要求改成蒸飯。這時項目經理說：小郭，你把那個煮菜功能給我換成蒸飯。這時，程序員小郭，找啊找，找遍了註釋，發現沒有煮菜功能，一氣之下，算了，自己寫吧，自己又寫了一個蒸飯的功能函數。之後帶有炒菜註釋的煮菜功能，在接下來的一個又一個程序員都不敢刪，也不管了。
看到了，註釋不維護，是不是很不好。這只是其中一個方法，如果你修改了大部分的方法，又沒有修改註釋，接下來接手的程序員又不敢亂動，還看不懂，自己又重新寫，代碼冗餘，混亂不堪，之後越來越爛，代碼越來越沒人管了，也不想幹了。
總結
代碼即註釋，寫註釋要注意分寸。如下：
-
用高質量的代碼代替註釋。
-
在複雜函數和重要的業務邏輯面試，還是必須要寫註釋的。
-
註釋需要維護，不是寫了就好。不維護，還不如不寫。
-
要學會命名，遵守規範，這樣才能夠培養出好習慣。