1. 短小
- 函數儘可能的維持在一屏可見的範圍內。20行封頂代碼最好。代碼短小除了閱讀輕鬆外，更便於理解，出錯的概率也比較小。
2. 只做一件事情
- 我們常常期望函數具有可擴展性，貌似有點不一致？？？
3. 每個函數一個抽象層級
- 每個函數都對應一個抽象層級
- 函數由相同抽象層級的其他函數組成
自頂向下讀代碼：向下規則
4. switch語句
xxxx
5. 使用描述性名稱
- “如果每個函數都讓你感到深合己意，那就是整潔代碼”
- 長而具有描述性的名稱比短卻費解的名稱要好
- 使用某種命名約定，讓函數名稱中的多個單詞容易閱讀，然後使用這些單詞給函數取個能說清其功用的名稱
- 命名方式上下保持一致
6. 函數參數
- 函數參數最好越少越好，理想個數爲0，其次1個，再次2個，儘量避免3個，有足夠多的理由才能使用3個以上參數
- 參數會帶來太多的概念性。（入參，出參）
- 參數會是測試的難度加大，難以保證測試覆蓋度
- 一元函數的普遍形式。 1. 詢問參數，2. 轉換參數 3. 事件
- 不要將flag作爲參數傳遞給函數，因爲這顯而易見的告知他人這個函數不只是做一件事情（false時一件事，true時另外一件事情）
- 二元函數 可以通過一些方法轉化爲一元函數，比如寫成某種對象的成員函數
- 多元參數，適時進行封裝
- 無副作用
還是隻能做一件事情，但即使函數承諾只做一件事情，但還是會做其他被藏起來的事。
如果函數名只是一個掩護，而在實現中做了與描述功能不相符或者額外的其他事情，但這是極其危險的。強調名副其實！
避免使用輸出參數，可以使用修改類的屬性方式替換。
7. 分隔指令與詢問
- 函數要麼做什麼事，要麼回答什麼事，二者擇其一
8. 使用異常替代返回錯誤碼
- 返回錯誤碼可能會導致深層次的嵌套結構。因爲需要做錯誤處理
- 使用try catch，可以將錯誤代碼從主路徑中分離出來
9. 抽離try/catch代碼塊
- 不要在主路徑中使用try/catch， 會導致代碼結構混亂
- 可以抽離出來封裝成函數
10. 錯誤處理就是一件事
- 這意味着，處理錯誤的函數不該做其他事情，所以這個函數的第一個單詞應該是try，另外catch/finally後面也不應該有其他內容。
11. 錯誤碼的依賴
- 返回錯誤碼通常暗示有某個類或者枚舉定義了所有的錯誤碼。
- 那麼其他使用這些錯誤碼的類就需要去include這個類/頭文件，那麼如果需要添加新的錯誤碼
- 就可能需要所有引用過的類都需要重新編譯
- 如果使用異常代替錯誤碼，新的異常可以直接從異常類中派生出來，無需重新編譯和重新部署。
12. 別重複自己
- 減少重複代碼
13. 結構化編程
- 遵循一個入口，一個出口原則，每個函數只能有一個return，循環中不能有break或continue語句，永遠不能有goto
- 這只是針對大函數，對於小函數沒有太大關係
- 另外DSP編程中循環中的break和continue除了破壞代碼結構之外，增加了跳轉破壞函數的並行性
- 所以函數只要保持短小，偶爾出現的return, break 或 continue語句沒有壞處，甚至還比單入單出原則更有表達力。
- 另外，溝通只在大函數中才有道理，所以儘量避免使用