從個人的角度來看，漂亮的代碼首先得滿足這么一點，可讀性強。

　　如何讓自己寫的代碼變得可讀性強呢？ 從最簡單也是最難的做起，有意義的名稱 + 減少方法的長度。

　　我看過很多遺留系統的代碼，里面大都充斥著大方法，多層縮進。如果不是逼不得已，個人是不愿意去讀的。就像讀文章一樣，寫的狗屁不通的文章你愿意去看嗎？ 而看文筆優雅的文章卻是一種享受。所以我們寫代碼要漂亮、要優雅。

　　這種代碼維護成本相當高，要改一個bug或者新增加一個極小的功能，都可以把人玩死。首先是一個方法上來就三四百行，硬看是看不懂的，為什么？舉這么幾個例子：

　　1. 沒有意義的變量名（或者大量縮寫），var a = xxx; var mmdi = xxx; 這種變量名稱，凡是不是作者的人都看不懂，有些作者還比較好，放個注釋在那。不過久而久之，代碼經過刪除、新增，注釋不是位置不對了，就是意義不對了，反而容易誤導。

　　2. 多層縮進。看一個if語句，腦子里就要記著，這里有個分支。如果if里面還有N層if加switch，立馬就會暈。

  if (aaa) {
    if(bb && cc) {
        ….
    } else if(xx) {
         …
     } else {}
   }

　　這段代碼讀下來，腦細胞不知道要死多少。

　　3. 過多條件組合。有時候經常看到這種代碼，if(aaa && bbb && (ccc || ddd)) {}。這也是種迷惑人的手段，條件組合有很多，一會或一會與，意圖不明。

　　4. 一個方法里邏輯過多，導致方法過長。比如說：

   function demo() {
   //從request中拿變量
   以下20行
   //看看cache中有無數據
    以下5行
   //調用這，調用那，做些處理
    以下50行
   //把某些數據進行轉換
    以下幾十行
   //把數據放到view中去
    ….
   }
   還有些更厲害的
   //begin, 某某新增，為了什么功能
   幾十行
   //end
   //begin，為了解決什么bug
   幾十行
   //end
   這樣下來，這個函數是沒法讀了，想要讀完都不容易，鼠標滾輪都得滾壞。

　　反例有很多很多，這里也不一一列舉了。下面我們看看到底怎樣做才能解決這個問題。

　　1. 要用有意義的命名，不管是變量還是方法或者類等等，讓人一眼看去，就明白這個東東是做什么的，它比注釋管用，因為注釋得另外去維護。

　　2. 不要用縮寫。凡是命名都寫全稱，不要怕名字長。

　　3. 限制方法長度。在代碼規范中強制要求，一個方法不能超過10行。這一點大多人聽起來不可思議，其實很容易做到，具體怎么做，《重構》那本書都有。核心就是抽取方法。

function demo() {
    get_all_params
    update_something
    put_something_into_view
  }

　　4. 減少縮進，一個方法中一兩級的縮進就ok了。

　　5. 關于上面過多條件組合的，簡單進行重構。凡是這種組合都抽取函數，if(is_user_admin())等。然后呢，在抽取的函數中也不要return aaa && bbb && ccc這種形式，寫成這樣：

if(aaa) {return true;}

if(bbb) {return true;}

 return false;

　　看起來很傻的寫法，其實很簡單可讀性很好，是好代碼。

　　這些都是一種習慣，習慣性的寫出有意義的名稱，習慣性的不斷重構減少方法長度，條件反射一般寫出漂亮的代碼，我們都稱之為代碼潔癖。

　　先從最基本的做起，寫代碼的時候花點時間想想怎么去命名，找同事來看看，這個名字好不好，容不容易看懂。花點時間琢磨一下，這段邏輯真的應該放在這里嗎，能不能抽取到一個方法中去呢？