看完上圖你是什麼反應？會罵人嗎？會就對了……，代碼整潔之道，是一條很漫長的路，註釋是其中一部分。 ...
看完上圖你是什麼反應？會罵人嗎？會就對了……，代碼整潔之道，是一條很漫長的路，註釋是其中一部分。
如果是一個很大的方法，要不要加註釋？一個大方法按照它的功能被分割成幾個小方法，這樣代碼就比較容易閱讀了，但有的童鞋說能在項目的deadline裡面搞出來就行了，哪有時間整理這種大方法？為了讓你的搭檔或者接手者，更輕鬆的理解，讓她/他少加班，抽時間還是整理一下吧。按照樹的結構，一個主幹，其他分支都是處理不同的邏輯。
如果是小方法能做到見名知意，就一定要見名知意，習慣總是要培養的，接一句雞湯：走得慢並不要緊，只要你堅持不停地走，那麼總有一天你能走到你想要到達的地方，能超過道旁那些不敢走的人。走正道！
大牛們總是說：代碼就是最好的註釋。可惜我還沒有達到那個程度。但是我依然嘗試著用命名代替註釋，發現自己做的並不對，如果你團隊的新人呢？比較複雜的方法，靠命名？所以這個時候還是建議把註釋寫的清清楚楚，其一：為了自己以後維護的方便； 其二：為了其他人接手的方便。
總結一下：
-
如果自己的英語不好
對我們來說第一語言是中文的，英語不好情況就不一樣了，這就是為什麼國人的建議大多要求註釋詳盡，讓代碼更易讀易懂；而老外的建議幾乎是儘可能的少；符合我國基本國情。
-
如果自己的水平還不夠
對於很複雜的邏輯，務必用12345的順序依次寫清楚；對於函數中的某個參數，需要解釋為什麼要設置這個參數，尤其是公用工具類裡面的函數---說清楚參數的背景含義，可以讓其他調用者理解的更加清晰。
-
如果整個團隊水平參差不齊
一般不要用英文寫。雖然這樣看起來格調很低，但勝在大家都能輕鬆的看懂。寫代碼不能太傲嬌，不能太任性，寫註釋也不要太傲嬌，目的是讓你的搭檔或者接手者，更輕鬆的理解，提高效率，早點回家老婆孩子熱炕頭。
我們不能保證每個團隊裡面的每個成員都是大神，寫該寫的註釋，單一定要去嘗試用方法名和變數名去替代註釋，說不定哪一天你也成為了大神？
稍後等於永不，行動起來……
