function getUsers($names) //描述利名稱 + 參數數量
{
    try {
       //一層抽象概念 + 只做一件事情
    } catch(NoException $exception) {
         //使用 try catch 取代錯誤代碼
    }

}

概念

簡短

1.每個函式都應該一清二楚，透露出本身的意圖，每個函式都帶領著你至下個函式，這就是函式該有的簡短
2.區塊和縮排 : 函式裡的巢狀結構不應該大過一到兩層

只做一件事情

1. 如果函式只做了函式名稱下同一層抽象概念的幾個步驟，那麼這個函式就只算是做了一件事情
2. 判斷方法 - 1.TO之段落 2. 看能不能從這個函式中提練出另一個新函式
3. 函式的段落 - 做一件事情的函式沒辦法被合理的分成不同的段落

每個函式只有一層抽象概念

1. 為了確定我們函式只做一件事情，我們需要確定再函式裡的敘述都在抽象概念的同一層次
2. 由上而下閱讀程式碼：降層準則 - 我們希望程式的閱讀就像由上而下的敘事，每個函式後面都接著下一層次的抽象概念 3. switch 敘述 - 總是在做 N 件事情

使用具備描述力的名稱

1. 使用某種命名慣例，可以使用多個易讀的字詞組合，並善加利用這些字詞組合，使函式名稱能自我說明該函式意圖

函式的參數

1. 函式參數的數量 0 > 1 > 2 > 3
2. 單一參數的常見形式 - 1.與這個參數有關的事情 2.對這個參數進行操作 3.只有參數輸入但是沒有輸出
3. 旗標Flag - 使用旗標參數很爛
4. 兩個參數的函式 - 兩個參數並不邪惡, 但你應該注意, 使用它們的代價, 如果有機制可以將兩個轉成一個要好好利用
5. 三個參數的函式 - 比兩個參數更難理解, 使用時要慎重考慮
6. 物理型態的參數 - 建立物件的方式減少參數, 當函式需要用2~3個參數時就要考慮是否要裝在一個物件裡
7. 參數串列 - 傳遞不同數量的參數, 一樣要遵守參數數量越少越好
8. 動詞和關鍵字 - 替函式選一個好名稱, 可以產生許多附加價值, 例如解釋函式的意圖, 解釋函式參數的順序及意圖

要無副作用

1. 做超過一件事情 2. 輸出型的參數 - 避免使用

指令和查詢要分離

1.函式應該要能做某件事情或回答某件事情, 但不應該兩者同時發生

用例外處理取代回傳錯誤代碼

1.提取try/catch區塊 - 將 try/catch 區塊變成一個 method
2.錯誤處理就是一件事情 - 一個處裡錯誤的函式, 應該不能再做其它事情
3.當你使用例外, 而非使用錯誤碼時, 新的例外可由例外類別衍生出來, 不必重新編譯或重新佈署, 就可以加入現有的程式中

不要重複自己

1. 重複程式碼是軟體裡邪惡的根源

結構化程式設計

1. 盡量保持只有一個進入點和離開點, 這是表示只能有一個 return

你要如何寫出這樣的函式?

一開始的程式碼總是又臭又長
逐漸開始琢磨和改善
最後直到符合書中的準則
不可能一開始就寫成這樣
書本作者也認為沒有人一開使就有辦這樣做到
而是逐漸精煉達到那樣的