究竟要不要寫代碼註釋？

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

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

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

大牛們老是說：代碼就是最好的註釋。惋惜我尚未達到那個程度。可是我依然嘗試着用命名代替註釋，發現本身作的並不對，若是你團隊的新人呢？比較複雜的方法，靠命名？因此這個時候仍是建議把註釋寫的清清楚楚，其一：爲了本身之後維護的方便； 其二：爲了其餘人接手的方便。

總結一下：

• 若是本身的英語很差

對咱們來講第一語言是中文的，英語很差狀況就不同了，這就是爲何國人的建議大多要求註釋詳盡，讓代碼更易讀易懂；而老外的建議幾乎是儘量的少；符合我國基本國情。

• 若是本身的水平還不夠

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

• 若是整個團隊水平良莠不齊

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

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

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