一群猴子在森林上竄下跳，抓著幾個酸桃子，得意洋洋的坐在樹上，確對自己造成的混亂熟視無睹。

一 序

沒錯，我們就是這么一群(Code)代碼(Monkey)猴子。當我們在編寫出“可以運行”的程序后，我們便得意洋洋的進入下一個任務(wù)，任由這些程序在我們眼皮底下腐爛，造成混亂。

Code Monkey

對于自己造成的混亂遲早都要付出高昂的代價去修復(fù)，與其這樣，我們還不如在編碼的時候就編寫“干凈的代碼”。對于這些“干凈的代碼”，我們可以遵循軟件開發(fā)中的5S原則：

• 整理：命名的規(guī)范
• 整頓：把你的代碼放在它應(yīng)該在的地方
• 清楚：整潔代碼
• 清潔：代碼風(fēng)格、實踐手段
• 身美：不斷改進

所有的原則都是為了遵循 “童子軍軍規(guī)” —— 讓營地比你來的時候更整潔

二 整潔的代碼

整潔的代碼沒有固定的標準，但有大體上的原則來規(guī)范代碼（代碼在我們離開時要比發(fā)現(xiàn)時更整潔）：

• 可以讓閱讀代碼的人感到愉悅 —— 可讀性
• 代碼的質(zhì)量
• 好的命名
• 只做一件事
• 減少依賴關(guān)系
• 可以通過所有測試
• 沒有重復(fù)代碼
• 包括少量的實體

三 有意義的命名

一個好的命名并不一定是一開始就寫好的，它是不斷被更好的名稱所替代的。一個好的命名遵循下列的規(guī)范：

• 名副其實：不需要被注釋也應(yīng)該被理解、看懂。一個名副其實的命名可以告訴讀者：
• 怎么用
• 做什么事
• 為什么存在
• 避免誤導(dǎo)：（I 、O），這到底是 I 還是 1,是 O 還是 0；（傻傻分不清）
• 做有意義的區(qū)分：
• 不要使用 a1 a2 a3
• 不要說廢話（student 就不要再寫成 studentInfo / studentData 了）
• 使用讀得出來的名稱：你應(yīng)該不想讓你的小伙伴一個方法名一個字母一個字母的讀出來吧
• 使用可搜索的名稱：不要使用硬編碼，盡量使用常量替代
• 一致的命名規(guī)則：比如查找都用 find*
• 不要使用雙關(guān)語

四 函數(shù)

還記得你曾經(jīng)寫過的幾百行代碼的函數(shù)嘛，現(xiàn)在在回去看看

所以寫出一手干凈的函數(shù)/方法代碼是非常重要的，這關(guān)系到你寫完代碼之后會被多人(xian)“夸”(qi)的問題，對于整潔的函數(shù)：

• 短?。?/li>
• 20 行以內(nèi)，不能再多了
• if / else /while 代碼塊理應(yīng)只該有一行代碼
• 每個函數(shù)/方法只干一件事（同一層級）
• 使用描述性的名稱
• 函數(shù)參數(shù)：
• 一元參數(shù)：有輸入應(yīng)該也有輸出
• 二元參數(shù)：盡量不要使用，除非參數(shù)是有序組成的(new Point(x,y))
• 三元+參數(shù)：封裝成類在傳過去吧
• 標識參數(shù)：不要傳過來，這是在違反一個函數(shù)/方法只干一件事的原則
• 使用異常替代返回碼
• 抽離 try-catch
• 別重復(fù)自己

五 注釋

回想當初，年輕的我們還在比看誰寫的注釋多，注釋多的更好。現(xiàn)在再看看當初寫的代碼，這是哪個程(da)序(sha)員(bi)寫的注釋，多久沒維護了都?，F(xiàn)在回過頭想想，當初寫注釋的目的是為了讓讀者更好的了解該函數(shù)的意義，而事實上，真正好的注釋就是想辦法不去寫注釋，一切盡在函數(shù)名稱上。除了好的注釋，其它的都是不(la)好(ji)的注釋：

• 法律信息
• 提供信息的注釋（時間格式...）
• 對意圖的解釋
• 警告
• TODO
• 公共 API

六 格式的目的

格式的最大好處就是可以提高可讀性，方便維護和拓展。代碼的格式可以分為：

垂直格式

• 概念間垂直方向上的間隔（空一行）
• 垂直方向上的靠近（緊密聯(lián)系的代碼放在一起，不要隔開）
• 垂直距離
• 變量聲明：靠近其使用位置
• 實體變量：類的頂部
• 相關(guān)函數(shù)：調(diào)用者放在被調(diào)用者的上方（靠近）

橫向格式

• 根據(jù)是否緊密相關(guān)進行：
• 隔離（等號兩邊加空格）
• 靠近：（乘號兩邊不加空格）
• 空范圍：將; 換行

while(...)
;

七 對象和數(shù)據(jù)結(jié)構(gòu)

數(shù)據(jù)抽象應(yīng)該盡可能的以抽象的形態(tài)表述數(shù)據(jù)，避免暴露過多的細節(jié)。
墨忒耳律(The Law of Demeter)：每個單元/對象/方法應(yīng)當對其它單元只擁有有限的了解。

在對象 O 的 M 方法中，只應(yīng)該訪問：

• 對象 O 本身
• M 方法的參數(shù)
• M 方法中創(chuàng)建或?qū)嵗膶ο?/li>
• 對象 O 直接的組件對象
• 在 O 的范圍內(nèi)可被全局訪問的全局變量

八 單元測試

TDD 三定律

• 在編寫不能通過的單元測試之前，不可編寫生產(chǎn)代碼
• 只可編寫剛好無法通過的單元測試，不能編譯也算不通過
• 只可編寫剛好足以通過當前代碼的生產(chǎn)代碼

整潔的測試可讀性（構(gòu)造、測試、校驗）一定是非常高的，在單元測試中一般將相關(guān)聯(lián)的語句和斷言放在一起。整潔的測試遵循 F.I.R.S.T. 規(guī)則:

• 快速
• 獨立：測試之間不該有相互依賴
• 可重復(fù)：任何環(huán)境下都能跑
• 自足驗證
• 及時：測試代碼先于生產(chǎn)代碼編寫

九 類

函數(shù)應(yīng)該足夠短小，類也應(yīng)該足夠短小。且類應(yīng)該

• 遵守單一權(quán)責(zé)原則：一個類應(yīng)該只有一個加以修改的理由（一個抽屜只放同一類物品）
• 保持高內(nèi)聚：類中應(yīng)該只有少量的實體變量，且類中的每個方法都應(yīng)該操作該實體

看完《代碼整潔之道》不禁感嘆，代碼原來應(yīng)該這么寫，自己原來寫的代碼真的是太(T)難(M)看(chou)了。但是感覺還不夠，還應(yīng)該有更多的整潔之道，在看《重構(gòu)》的時候希望能有更大的啟發(fā)。