記得剛參加工作，經理就給組裡的人發了一份他寫的專案程式碼，當時面對這樣一個大專案，看了幾天，組裡的人都抱怨程式碼沒有註釋，難讀。這是經理就說了句話，我記到了現在： “你們老是抱怨別人的程式碼沒有註釋，可是你們有給自己的程式碼寫註釋嗎？” 的確如此，我們希望看到別人的註釋，同時又不想給自己的程式碼寫註釋。對於那些開源大型專案，一般會有良好的註釋，團隊本身也非常優秀，管理規範，專案擁有大量的使用者，這類專案一般不會缺少註釋，是否自願的就不一定了。 想必都讀過程式碼的人都有體會，在自己水平範圍內，實現某個功能和看懂別人的實現程式碼，後者的難度往往大於前者。儘管很多人說好程式碼不需要註釋，本身就是“自注釋”。但是你會發現，說這種話的人，要麼是大牛，要麼是菜鳥。就身邊的觀察而已，當讀別人的程式碼時，是希望有必要的註釋的。 大多數公司裡，接手別人的程式碼，是缺乏必要的註釋的。github上的個人Repositories是普遍缺乏註釋的。他們為什麼不寫註釋？
因為寫註釋是利他行為。 特別是公司專案，接手程式碼的是同職位的人，互為競爭。因此，即使公司規範中要求寫註釋，你也明明知道，以後會有人接手你的專案，可是你很少會為後人寫註釋。我接手過10個專案，只有一個專案是有少許註釋的。 帶有註釋的程式碼已成為一種奢望。如果你是專案組長，與其勉強同事們寫上註釋，不如提倡Coding Without Comments。當不提倡寫註釋時，他們會更用心地寫好變數名，函式名。不得不承認，註釋雖好，寫好卻難。比如維護困難，當實現修改後，註釋經常忘記同步。有的註釋是模糊的，多餘的。時間久遠後，誰也搞不懂這段註釋是什麼意思了。可見，即使要寫註釋，儘量是簡明扼要。 寫好註釋跟寫好程式碼一樣，是藝術活。 (2016/4/1)