一、前言
這篇文章將會分享 Clean Code 關於函式的重點，內容主要以個人閱讀後有印象的部分著手，有興趣了解更多請自行購買這本書。
二、Clean Code
這本書出自於某一位程式設計的大師，他為程式設計建立了一個程式設計的流派，Clean Code 對每一位程式設計師的意義都不盡相同，對某些人來說，這是維護、命名的準則，對某些人來說，則是程式開發的架構與雛形。
1. 簡潔
這本書最為著名的就是簡潔，簡單扼要的程式邏輯、清楚易懂的程式設計知識與架構，這是它廣為流傳的核心守則，這本書不會實際教導如何寫程式，它會把寫程式要注意、要避免的事情一步步告訴設計師。
2. 直覺
其中最重要的一件事情，是Clean Code 強調程式是一種語言，因此在撰寫裡面的每一個字都要設計與思考，就像寫一本書一樣，要能讓人一看就懂，不需要經過轉化或推測，能很直覺的就理解程式碼的內容，因此也容易維護。
3. 零重複
它的一項特徵是程式碼不會有重複的內容，同一功能的程式寫完之後就不用再撰寫第二次，能讓程式碼的數量大為減少，重複利用的同時依然保持單一職責的設計模式。
三、函式核心準則
如同構思遊戲三本柱一樣，我決定把函式也提取出三項最核心的準則，第一項是簡短；第二項是指做一件事情；第三件是函式是程式語言的動詞。
1. 簡短的內容
在寫程式的時候，很容易因為要測試構想的內容是否正確，就會把所有東西寫在一項函式裡面，甚至名稱就叫做「XXXTest」，當然這沒什麼不好，不過當測試完畢後，記得不要直接使用。
重新撰寫一遍函式，每個函式的內容要簡短，如果能兩行就不要三行；如果能一行就不要兩行。讓函式精簡到足夠單純，沒有多餘的內容，這代表著函示沒有能再拆出去的任何一行程式碼。
2. 只做一件事情
每個函式應該只服務於一件事情，譬如玩家跳躍很多人會撰寫一個函式，這個函式包含地面檢測並給予玩家推力，這應該至少拆成兩個函式。第一個函式處理地面檢測；第二個函式處理玩家跳躍。
最容易檢查函式有沒有做超過一件事情的方法，就是確認函式的名稱是否足夠準確，如果名稱無法代表整個函式所處理的任務，那這個函式可能做了不只一件事情。
3. 函式是程式語言的動詞
我覺得這本書最後為函式作的結尾很棒，「函式式這個語言裡的動詞，類別則是這個語言裡的名詞。」程式設計是一種語言設計的藝術，如果寫作要有層次與先後順序的差別，寫程式亦如此。
四、函式注意事項
這裡會分享一些重要但不需要時刻注意的事情。
1. 只有一層抽象概念
如何確定函式只做一件事情，從抽象層面去審視是一件不錯的做法，所謂的抽象念，就是它裡面的內容包刮哪些類型，如果既定義了變數的值，又執行了某一項函式，那它應該不只處理了一件事情。
2. 寫作程式碼 | 降層準則
寫程式的時候可以參考降層準則，我自己稱之為寫作程式碼，第一行函式裡面總共執行了三個函式，下面就逐一解釋這三行函式做了哪些事情，玩家的閱讀順序由上往下，不需要跳著閱讀。
3. 具描述能力的名稱
在取名的時候，要注意取名是否代表包含的功能，如果一個函式叫做「Player」不如叫做「PlayerSystem」；「PlayerMove」不如說明是提供推力還是提供方向。
描述能力的目的在於讓未來閱讀程式碼不需要閱讀內容，在閱讀一大堆函式的時候其他設計師不用去理解你寫了什麼內容，只需要學會使用即可。
4. 參數
最好不要使用任何參數，如果能使用一個參數就不要使用兩個；如果能不用使用參數就不要使用任何參數。參數通常會與函式搭配，如果函式的命名是一個動詞，那參數就應該要是一個名詞，反之。
5. 避免使用 Flag 函式
我當初在看到 Flag 函式的時候思考了一下這式什麼東西，在經過搜尋後才知道這是 bool 函式，如果 true 執行一個事件、如果false 執行另一個事件，但這本身就代表不只處理一個事情，所以要避免使用 flag 函式。
五、後記
這種概念性的書籍很有用處，至少我在看完命名跟函式以後我就有「我成長了很多」的感覺，在寫程式的時候也順利了不少。
達人
