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