如何編寫清晰的函式
最近重新在讀《clean code》，讀到第三章函式，裡面列舉出了很多編寫函式的準則，比如：
1. 短小
2. 只做一件事
3. 函式最好不要有引數
...
第一次讀的時候，會把這些準則記下來，就像學生時代去記課本一樣，自從看了一些批判性思維書籍之後，會帶著一些問題來看待這些原則，比如：
1. 短小（多長的函式算短小，為什麼函式需要短小）
2. 只做一件事 （什麼叫一件事，比如是吃飯算一件事，還是點菜，下單，吃飯，結賬各算一件事，為什麼只做一件事）
3. 函式最後不要有引數（為什麼不要帶引數）
...
有了問題之後會在書中尋找答案，尋找作者的論據，發現其實作者很多準則是依據經驗總結得出，無法得出條條框框的原因，這個時候就無法去相信作者的結論，但是可以去思考作者的理由，或者是是什麼樣原則推匯出這些準則出來的。
前些天看了一篇文章中也提到，平時像GOF這些設計模式是術，而面向物件的思維才是道，有了道之後在遇到設計決策的時候會心中有數，也就是無招勝有招。
從函式的這些準則以及作者不成文的理由中看出編寫的原則只有一個：便於閱讀與理解
比如如果一個警察需要去了解一個嫌疑人一天內做了什麼，可能是需要嫌疑人先做個簡短的描敘：
早上去吃早飯，然後剪頭，去上網，吃午飯...
然後如果對感興趣的事情詳細瞭解。
嫌疑人的一天就是一個函式，吃早飯、剪頭、上網、吃午飯等等就很短小，而不是一開始就把所有的細節全盤說出。
如果嫌疑人在吃早飯的過程中去一趟銀行，這個資訊對警察比較有用，但是隱含在了吃早飯中，這就類似於一個函式做了多件事，並不是不可以，但是很難用一個簡短的詞語進行概括（函式名），也就給閱讀者帶來了困難。
等等其它的準則都是基於這個原則來進行，因此在自己設計函式時，可以參考既有的設計準則，也可以自創一些其它的方式以及對現有的準則進行改良，只有便於閱讀即可。
附上部分常用準則：
1. 只做一件事
2. 同一抽象層
3. 無副作用