碼出優美

　　一份擁有良好可讀性和拓展性的代碼是項目裏的良藥，它不只看着舒服，改起來也方便，甚至還能重用，各模塊邏輯分明。「見碼知功底」，而要達到高手那種簡潔有力的境界，須要進行大量的總結和練習，今天咱們就來談談如何寫出優美的代碼。

　　

命名

　　好的命名應該具備以下特徵：

　　1，意思正確。這是最基本的要求，不要掛羊頭賣狗肉，詞不達意，要一眼就知道什麼意思。就算一眼看不出來，複製到有道詞典翻譯一下也能知道什麼意思；

　　2，單複數分明。若是是一個數組，要麼加s/es結尾代表其是複數，要麼加入list表示它是一個數組。如cars，carList均可以表達一個車的列表；

　　3，慎用縮略詞。縮略詞可讓咱們的命名更加簡潔，可是一！定！要！是！業！界！通！用！縮！略！詞！好比info原意爲information，msg原意爲message，fn原意function，conf原意config等等，這些縮略詞都是業內傳統了，你們都知道什麼意思，切記不要本身亂造縮略詞；

　　4，有具體含義。根據業務場景去命名，而不是根據抽象命名；好比getUnreadMsgList，一看就知道是獲取未讀消息列表的意思，而getData這種說了跟沒說同樣，缺少具體含義。

 

註釋

　　有表達力的代碼是不須要註釋的。好比一個init函數，一看就知道是用於作一些初始化的工做，不必寫多餘的註釋來講明。

　　可是有一些場景註釋是很是有必要的，下面幾種場景要添加註釋：

　　1，一些針對特殊業務場景而訂製的特殊邏輯。好比當咱們更新我的信息的時候，因爲後端的問題，須要少傳一個諸如生日的信息，或者更新頭像時要多傳一個時間戳來供其餘業務之後使用。這些莫名其妙的增刪屬性，若是不加以註釋，將致使後續本身都沒法理解；

　　2，可能會出現隱患的代碼。因爲自身水平所限，或者自己技術上就沒法實現，只能經過一些特殊技巧來仿製一些效果，每每會存在安全隱患，好比：用戶操做太快會出問題，網絡太慢會出問題，某個接口調不通這頁面會全掛了，一些特殊的操做會引發的暫時沒法解決的bug等等場景，都須要註釋說明；

　　3，涉及到某些高深的或者生僻的技術知識。這種也要註釋，以提醒本身和其餘開發者。

　　總的來講，在註釋裏「爲何這麼作」比「這玩意是什麼」重要得多，註釋不要濫用，也不能不用。

　　

函數

　　函數是代碼的靈魂，也是寫邏輯的載體，如下幾個要求是判斷一個開發者函數寫的好很差的標準。

　　1，是否是單一職責。一個函數應該只作一件事，而這件事應該能經過函數名就能夠清晰的展現。這是一個很是好的特性，一個辣雞的函數可能動輒幾百行代碼，各類邏輯堆積在一塊兒，看得人頭腦發暈，甚至開發者本身都理不清楚；判斷這個函數是否是單一職責的技巧很簡單：看看它還能不能再拆分。

　　2，有沒有層級之分。函數與函數之間是有身份地位之分的，有負責總體大局觀的高級函數，也有專一細節的打工仔低級函數。若是不創建起層級結構，就容易迷失在細節的海洋裏。好比：

　　

 

 

　　對於作一頓飯這個函數來講，他不須要關心諸如買菜時反覆挑選這種細節，它只須要知道，大概有三個大步驟就好了。因此這段邏輯會根據其地位拆分出不一樣等級的函數，假設沒有層級之分，那麼從第一步的「搭公交」一直寫到最後一步的「倒垃圾」，這東西會變得極難維護。

 

　　3，承載的場景是否足夠簡單。有時候咱們會遇到這樣一種場景：一個函數在不少地方都會用到，可是不一樣地方傳入的參數不同，這樣咱們爲了函數的通用性，就針對入參作了不少種場景的識別，致使入參很是多，裏面還須要根據不一樣的場景作邏輯上的細微調整。因此單單是取傳入參數都夠嗆了，一堆的if else或switch case。

　　這個函數太難了，並且這已經違背了函數的單一職責原則，它在裏面作了多種場景的判斷，從而表現出不一樣的行爲，但這些行爲又不是徹底不一樣，而是「大致相同」，若是重寫好像又會增長不少的重複的代碼。解決的方法是作更小粒度的拆分，將那些真正與業務脫鉤的部分抽離出來，而不一樣場景對應不一樣的處理函數，剛剛抽離的業務脫鉤函數正好做爲這些不一樣場景函數公共部分！