代碼整潔之道——函數

1. 規則

   1. 短小，更短小。
      要讓每一個函數遵循單一職責原則
   2. 代碼塊和縮進
      對於if,else,while等語句，如果其中的代碼塊邏輯複雜，應提取方法。
      函數的縮進層級不該多餘一層或兩層，易於閱讀和理解
   3. 只做一件事
      函數應該做一件事，做好一件事，只做一件事。
      判斷函數是否只做了一件事，看能否再拆分出一個函數
   4. 每一個函數一個抽象層級
      要確保函數只做一件事，函數中的語句都要在同一抽象層級上。抽象層級混雜，會讓人迷惑，細節與基礎概念混雜，會讓更多的細節在函數中糾結起來。
   5. switch語句
      短小的switch語句很難寫。Switch天生就是做N件事。但是我們沒法避開它，他會讓我們違反單一職責、開閉原則。我們可以通過將switch語句埋藏於較低的抽象層級。
   6. 使用描述性的名稱
      好的名稱讓人更好理解代碼，函數越短小，功能越集中，就越便於取個好名字。
      別害怕長名稱， 別害怕花時間去名稱。
      命名方式要保持一致，使用與模塊名一脈相承的詞語命名
      選擇描述性的名稱能理清你關於模塊的設計思路，並幫你改進，追求好名稱，往往導致對代碼的改善重構。

   7. 函數參數
      參數越少越好。向少函數看齊
      7.1 一元函數的普遍形式 函數名能體現參數的作用 轉換 還是 操作
      7.2 標識參數
      向函數傳入布爾值是不好的做法，起碼它表示函數處理兩種事情，可將函數一份爲二。
      7.3 二元函數 能正確區分函數參數意義
      7.4 三元函數
      7.5 參數對象 當參數過多時。
      7.6 參數列表 傳入的參數數量可變
      7.7 動詞與關鍵字
      好的名字更好地解釋函數的意圖，以及函數的順序和意圖。
      如：

      write(name )   --- >   writeField(name)
      assertEqual(expected, actual)  assertExpectedEqualActual( ,)

   8. 無副作用
      函數隱含了做另一件事。
      避免使用輸出參數
   9. 分割指令和詢問
      函數要麼做某事，要麼回答某事。二者不可得兼。
   10. 使用異常替代返回錯誤碼
       抽離Try/Catch代碼塊，另外形成函數。
       錯誤處理就是一件事。 處理錯誤的函數不該做其他事
       Error.java 依賴磁鐵 使用異常代替錯誤碼。新異常從異常類派生。
   11. 別重複自己 控制和消除重複
   12. 結構化編程
       每個函數，函數中的每個代碼塊都應該有一個入口，一個出口。
       但是隻要函數短小，偶爾出現return、break、continue可以。Goto只有在大函數中才有道理，避免使用。

2. 如何寫出整潔的函數：
   打磨代碼，分解函數、修改名稱、消除重複 縮短和重新安置方法，拆散類。

3. 函數的目的：
   真正的目標在於講述系統的故事，編寫函數必須乾淨利落地拼接在一起，形成一種精確而清晰的語言，幫你講故事

4. ？函數是否非得要特別小：
   按照職責去劃分函數， 不一定要分的特別小，關鍵思路是要通過函數劃分，類的設計體現出來你的代碼框架邏輯來