#代碼整潔之道 - 閱讀筆記（二）
第三章 函數
很喜歡第三章的插圖：龐大、畸形、混亂，表征不好的函數構造。
好的函數應該具備的特征包括：
- 短小
- 隻做一件事
- 每個函數一個抽象層級
- switch語句
- 使用描述性名稱
- 函數參數（盡量少）
- 無副作用
- 分割指令與詢問
- 使用異常傳回替代錯誤碼
- 别重複自己
- 結構化程式設計
先看一段好的函數與不好的函數：
【圖檔加載不出來，自行看書，見章節：3-0】
這兩段代碼，很明顯就看得出來那段代碼是好的。從直覺上描述：好的代碼就是易懂的。針對于上述幾種規則，對個别常見錯誤進行詳細說明。
#3.1 短小
函數的第一規則是要短小。
短小在于：函數包括的行數不能太長，建議不超過20行，每行包括的字元不能太多，建議不超過150個字元。
代碼塊和縮進
if語句、else語句、while語句等，其中的代碼塊應該隻有一行。該行大抵應該是一個函數調用語句。這樣不但能保持函數短小，而且因為塊内調用的函數擁有較具說明性的名稱，進而增加了文檔上的價值。
這也意味着函數不應該達到足以容納嵌套結構。是以，函數的縮進層級不應該多于一層或兩層。這樣的函數才更加易于閱讀和了解。
#3.2 隻做一件事
根據縮寫的代碼，完成具體的單個業務子產品，不要嵌套！！！
#3.3 每個函數一個抽象層級
要確定函數隻做一件事，函數中的語句都要在同一抽象層級上。混雜不同抽象層級，往往讓人迷惑。可能無法判斷某個表達式是基礎概念還是細節。更惡劣的是，細節與基礎概念混雜。
自頂向下讀代碼，向下規則：想要代碼擁有自頂向下的閱讀順序。我們想要讓每個函數後面都跟着位于下一抽象層級的函數，這樣一來，在檢視函數清單時，就能循抽象層級向下閱讀了。如：
#3.6 函數參數
最理想的參數數量是0，其次是1，再次是2。參數傳遞時，具有太多的概念性，每次都要翻譯一遍，不易于了解。從測試角度看，參數越多，編寫確定參數的各種組合運作正常的測試用例，是很渾南的事情。
##3.6.1 一進制函數的普遍形式
向函數傳遞單個參數的兩種普遍理由：（一）問關于那個參數的問題；（二）函數是一個事件，利用該參數修改系統狀态。
第一種理由：問關于那個參數的問題，操作該參數，将其轉換為其他什麼東西，要在一緻的上下文使用這兩種形式。
第二種理由：程式将函數作為是一個事件，使用該參數修改系統狀态，小心使用這種形式，應該讓讀者很清楚地了解他是個事件，謹慎的選用名稱和上下文。
##3.6.2 辨別參數
辨別參數不應該傳入，将true和false作為參數傳入函數。
##3.6.3 二進制函數
二進制函數的業務意義要很清楚。
##3.6.5 參數對象
如果函數看來需要兩個、三個或以上的額參數，就說明其中一些參數應該封裝為類了。
從參數建立對象，進而減少參數數量，看起來想作弊，但實則并非如此。當一組參數被共同傳遞，往往就是該有自己名稱的某個概念的一部分。
##3.9 使用異常替代傳回錯誤碼
從指令式函數傳回錯誤碼輕微違反了指令與詢問分割的規則，鼓勵了再if語句判斷中把志玲當做表達式使用。
錯誤示例為：
正确示例為：
使代碼更加簡化，且易于了解。
額(⊙o⊙)…，想要寫出好的函數，要寫，複看，複檢，再複檢。