看完上圖你是什麽反應？會罵人嗎？會就對了……，代碼整潔之道，是一條很漫長的路，註釋是其中一部分。

如果是一個很大的方法，要不要加註釋？一個大方法按照它的功能被分割成幾個小方法，這樣代碼就比較容易閱讀了，但有的童鞋說能在項目的deadline裏面搞出來就行了，哪有時間整理這種大方法？為了讓你的搭檔或者接手者，更輕松的理解，讓她/他少加班，抽時間還是整理一下吧。按照樹的結構，一個主幹，其他分支都是處理不同的邏輯。

如果是小方法能做到見名知意，就一定要見名知意，習慣總是要培養的，接一句雞湯：走得慢並不要緊，只要你堅持不停地走，那麽總有一天你能走到你想要到達的地方，能超過道旁那些不敢走的人。走正道！

大牛們總是說：代碼就是最好的註釋。可惜我還沒有達到那個程度。但是我依然嘗試著用命名代替註釋，發現自己做的並不對，如果你團隊的新人呢？比較復雜的方法，靠命名？所以這個時候還是建議把註釋寫的清清楚楚，其一：為了自己以後維護的方便； 其二：為了其他人接手的方便。

總結一下：

• 如果自己的英語不好

對我們來說第一語言是中文的，英語不好情況就不一樣了，這就是為什麽國人的建議大多要求註釋詳盡，讓代碼更易讀易懂；而老外的建議幾乎是盡可能的少；符合我國基本國情。

• 如果自己的水平還不夠

對於很復雜的邏輯，務必用12345的順序依次寫清楚；對於函數中的某個參數，需要解釋為什麽要設置這個參數，尤其是公用工具類裏面的函數---說清楚參數的背景含義，可以讓其他調用者理解的更加清晰。

• 如果整個團隊水平參差不齊

一般不要用英文寫。雖然這樣看起來格調很低，但勝在大家都能輕松的看懂。寫代碼不能太傲嬌，不能太任性，寫註釋也不要太傲嬌，目的是讓你的搭檔或者接手者，更輕松的理解，提高效率，早點回家老婆孩子熱炕頭。

我們不能保證每個團隊裏面的每個成員都是大神，寫該寫的註釋，單一定要去嘗試用方法名和變量名去替代註釋，說不定哪一天你也成為了大神？

稍後等於永不，行動起來……

究竟要不要寫代碼註釋？