程序猿作為地球上最為神奇的物種之一，幹過不少驚天地泣鬼神的雄圖大業，同樣給人們留下了不少茶餘飯後談論的梗。在普通人們眼中，程序猿是神秘的，是不修邊幅的，是沒日沒夜加班的工作狂；但在程序猿眼中，自己是帥氣的，拯救世界的，一枝梨花壓海棠的科技先驅。
程序猿的豐功偉績，最直接的體現就是像藝術品一樣的代碼，行雲流水、一氣呵成。但不是所有的程序猿都能看懂別人寫的代碼，就像不是所有的人都會欣賞藝術品一樣。畢竟代碼是用於業務生產，為了讓別人能夠更好理解自己的作品，也為了讓自己能夠更深刻的記住創作藝術品的過程，程序猿對自己的作品進行了加工——註釋。
註釋，顧名思義，就是對代碼進行釋義。註釋不是寫給機器的語言，不參與到代碼的編譯、連接、工作中去，而是寫給人看的內容。眾所周知，代碼，是讓計算機按照人的預想進行工作，註釋並沒有讓代碼運行得更加快，那麼註釋到底扮演者什麼樣的角色呢？程序猿和註釋之間又有怎樣的故事呢？
註釋是什麼？
註釋就是對代碼的解釋和說明，其目的是讓人們能夠更加輕鬆地瞭解代碼。註釋是編寫程序時，寫程序的人給一個語句、程序段、函數等的解釋或提示，能提高程序代碼的可讀性
為什麼寫註釋？
1.好記性不如爛筆頭
用於業務生產的程序，通常都不是寥寥幾語了事，而是大篇大篇的代碼，更有甚者，代碼行數千萬級別。雖說現在編程語言越來越高級、方便，對程序員越來越友好，大大縮小了代碼行數，但功能全面的、性能穩定的代碼依然有不小的篇幅。程序員在寫代碼的時候，語法規則雖然不難、不多，但是參數、函數、變量等等自定義的元素依然有很大的變化。代碼再有規則，但畢竟不是人類語言，不能一眼看明，再加上篇幅巨大，難免會有寫了後面往前面的尷尬處境。再加上前後代碼寫的時間有差異，程序員想要記住自己所寫的所有函數、變量、參數，也是很困難的。與其花時間記住這些函數、參數，不如一行註釋來得更快。
“
PHP-小星星-廣州：曾經，一個東西，寫的時候思路清晰，然後半年後愣是沒看懂。
PHP-Coeus-安徽：別說半年了，我上週寫的一個方法，現在都已經不知道上週開了什麼腦洞。
寫代碼要和寫註釋同步進行，對作品進行闡述，這樣不但可以預防寫後忘前的尷尬處境，還能讓自己的創造思路更加清晰。
古人云：好記性不如爛筆頭。
2.我為人人，人人為我
書寫篇幅巨大的代碼是一個宏偉的工程，這樣的工程通常不是一己之力能夠完成，眾人拾柴火炎高，眾人划槳開大船。談及到協同工作，首先要一個共同的標準，艄公多了打翻船的道理大家都明白。
“
Web-白楊-鄭州認為：一般立項的時候有規範文檔，對象、函數聲明一系列都要求一致。
但每一個程序員對藝術的理解不一樣，創造藝術品的方式和過程也會大相徑庭。但大家都是一起幹活，工期到了拿不出產品難免又要被工頭教訓。
程序員：“怎能讓自己的藝術屈服於生活，簡直是侮辱。”
工頭：“好好好，聽你的，只要你不寫 :(){ :|:& };: （fork炸彈）。但是你總得讓你的小夥伴能和你一起幹活吧，你的小夥伴得知道你幹了啥是吧。”
程序員：“那我寫好註釋，他們就能領悟到我的藝術了吧。”
工頭：“小夥子不錯，覺悟很高，中午盒飯加雞腿。”
“
PHP-Coeus-安徽：註釋寫的多少、寫的是否詳細，也影響了使用、修改你代碼的人員的門檻。
為了更好的協同開發，和小夥伴能夠一起愉快的玩耍，寫一個清楚明白的註釋是非常重要的，相愛沒有那麼容易，每個程序員有他的怪癖。如果每一個參與到項目開發中的程序員都能將代碼用心寫好，這無疑是協同開發一個利好因素。而且，你的註釋也會讓對你代碼頂禮膜拜的初學者獲益匪淺。
古人亦云：我為人人，人人為我。
3.前人栽樹，後人乘涼
維護過別人代碼的程序員，都應該經歷過一種切膚之痛——因為沒有註釋或者註釋不清楚而導致完全無法理解這代碼。創作者的藝術品，接盤俠的毀滅日。
創作者眼中的代碼
接盤俠眼中的代碼
其實這並不誇張，因為編程語言的特點，每位藝術大師都有足夠的發揮空間，但天馬行空的想象確實會讓後人難以琢磨。簡直就是前人栽樹，後人吃土的節奏。
誰也不想看到這樣的代碼，單單是要看懂就廢了九牛二虎之力，分分鐘吐血的節奏啊。
程序員：“我去，這段代碼什麼意思？這個調用是想幹嘛？哪裡又冒出來這麼個玩意兒？老闆，我想死。”
工頭：“想死都不行，你知道該怎麼寫代碼了麼？”
程序員：“我知道了，我一定要寫好註釋，為以後的工作鋪平道路。”
工頭：“嗯嗯，小夥子很有遠見，看來以後是要接我的班了。”
程序員：“我接了你的位置，那你呢？”
工頭：“我去做產品經理。”
程序員：“。。。。。。。。。。。。。。。。”
寫好註釋，會為業務的發展和程序的迭代提供不少便利，誰都不想當接盤俠，那就誰也別做隔壁老王。
古人還雲：前人栽樹，後人乘涼。
當前IT行業的發展趨勢，系統的迭代、程序的重構、工作的交接、對新進人員的培訓等事情越來越多，這些事情無一例外都會把已經寫過的代碼重新或者重複閱讀，如果在初始編寫代碼時，就做到完整、清晰明瞭的代碼註釋，對後續工作會有巨大的幫助。不僅提高工作效率，還能加固小夥伴之間的友誼。事實上，就算只是自己看自己的代碼，如果有註釋，也能加深印象，縮短代碼查找時間。因此，任何開發人員，都應該養成良好的代碼註釋習慣。
如何寫出漂亮的註釋
同代碼一樣，漂亮、有用的註釋會給藝術品錦上添花。要寫出好的註釋，一樣需要技巧。
首先，註釋是給人看的，要能讓人一眼明白其中的含義，不能拐彎抹角。
“
PHP-Coeus-安徽：一般按照規範來，看變量名，基本上都會知道方法是做什麼的，變量是什麼，需要註釋的內容就是，為什麼我要在這裡調用另一個方法，為什麼我要修改這個class狀態值。
後端接口開發-劉聲傑-成都：我的註釋就是：首先一定要寫明白這個是做什麼的，而且是什麼時候寫的，然後如果刪除了，一定要添加一個刪除標籤說明，尤其對於返回值，一定要說明每種情況，對於已經有替代方法的，一定要表明優秀用，每個參數的類型是什麼等等。
其次，註釋可以進行一個分類。
“
Web-白楊-鄭州：我習慣點亮以後，開頭註釋一個目錄，然後分ABC種類標色，A類是加進去肯定跑不動，B類是加進去能跑一半 ，C類是我都不知道的鬼代碼。。。。
第三，註釋也要恰到好處。
“
PHP-Coeus-安徽：之前我帶一個實習生和他說 ，你要有註釋的習慣，然後看他的代碼：
$a = $b+$c; // 做b、c加法。
這就看得我尷尬癌犯了，這強迫症晚期了吧。要做合適的註釋，而不是所有的代碼都進行了註釋，這增加了工作量，卻也沒有對代碼維護者有任何幫助。
第四，註釋可以保存代碼痕跡。
程序員在修改了代碼以後，未測試之前，代碼的質量是無法得到有保證的，有可能會被改得更糟糕，這時可能需要恢復到之前的代碼，如果你把之前的舊代碼刪除了的話，工作會變得複雜起來。
“
後端接口開發-劉聲傑-成都：重構部分代碼的時候，有時會保留部分之前的代碼，註釋掉，直到運行穩定以後，才慢慢的將其刪除掉，如果以後需要恢復，就看SVN記錄。
現在讓我們來看看漂亮的註釋到底什麼樣子：
Java-勇波-北京
PHP-coeus-安徽
【寫在最後】
羅馬不是一天建成的，寫註釋也是一個循序漸進的學習過程。寫註釋和寫代碼一樣，需要多加練習，掌握一套自己熟練的註釋方法。同時，在參考大神的代碼時，也可以借鑑大神寫註釋的方法，從而提升自己寫註釋的功力。
閱讀更多 程序員西西 的文章
