乾淨的程式碼： 編寫可讀的函式

以下是 clean Code 關於編寫可讀函式的建議的摘要。

這個建議是針對用 OOP 語言編寫的函式，儘管許多概念會延續到其他程式設計正規化。

原則 1 - 小！

• 你的大部分功能應該少於15行，而且幾乎不應該超過20行。
• 你應該總是能夠把整個函式放在你的顯示器上。如果你不能，那麼你可能需要將該函式分解成不同的函式。
• 如果你遵循這個原則，就意味著你的函式不會大到可以容納幾個巢狀結構。你將無法裝下一個迴圈，然後在這個迴圈裡面裝下一個巢狀的if/else語句，等等。
• 相反，你應該讓這些巢狀結構成為獨立的函式呼叫。這也增加了文件的價值，因為這些函式會有很好的描述性的名字來解釋它們做什麼。

原則 2 - 做一件事

• 另一種陳述原則1的方式是，你的函式應該只做一件事。
• 一個好的啟發式方法是看你是否能從你的函式中提取一些程式碼，並將這些程式碼變成一個新的函式，其名稱不僅僅是對其實現的重述。
• 如果你能做到這一點，那就表明你的函式在做多件事情，你應該進一步將其分解。

原則 3 - 每個函式的一個抽象級別

• 你的程式經常可以被劃分為不同的抽象層，每一層都代表相同資訊和過程的不同模型，但方式不同。

  一個例子是，如果你正在開發一個程式來刮取一個網站，解析一些資料，然後把這些資料放到一個資料庫中。

  一個抽象層是你向網站的伺服器傳送HTTP請求後得到的HTML字串。

• 你把這個HTML字串傳送到你的第二層抽象，在那裡，一個HTML解析器把這個字串轉換成一個物件，其中HTML頁面被表示為一個巢狀的資料結構（如果你想要一個更具體的例子，請閱讀BeautifulSoup）。這是第二層的抽象。
• 第三層抽象可以是你從HTML頁面物件中提取你需要的特定資料，並將這些資料儲存在一個陣列中。
• 第四層抽象是將陣列中的資料寫入資料庫。

 一個函式中的語句應該都在同一個抽象層次上。

你不應該在同一個函式中操作HTML字串物件和寫入資料庫。

相反，"清潔程式碼 "建議採用 "下降法則"（The Stepdown Rule），即你的程式碼可以作為一個自上而下的敘事來閱讀。

每個函式後面都應該有一個下一層抽象的函式。這樣一來，當你閱讀程式時，你就會在通過函式列表時，每次都會下降一層抽象概念。

原則 4 - 使用描述性名稱

如果你遵循前三個原則，那麼想出一個名字應該不會太難。

你的功能越小、越集中，就越容易想出一個名字。

不要害怕讓你的名字變長。一個長的、描述性的名字比一個短的、模糊的名字要好得多。你的編輯器的自動完成功能應該使你很容易寫出帶有長函式名稱的程式碼。

另外，使用一種命名慣例，允許在函式名中輕鬆讀出多個單詞。CamelCase就是一個例子。

原則 5 - 使用更少的函式引數

一個函式的理想引數數是零。應該避免一個函式有三個以上的引數。

有很多函式引數會使你更難閱讀和理解函式，因為它迫使你知道額外的細節（而這些細節通常來自不同的抽象層）。

此外，有很多函式引數會使你更難編寫測試。你必須寫出所有的測試用例，以確保所有不同的引數組合都能正常工作！你必須寫出所有的引數。

原則 6 - 避免副作用

副作用是您的函式在其本地環境之外修改某些狀態變數的地方，除了返回一個值（預期效果）。

一個示例可能是從資料庫中讀取某個值然後返回該值的函式。

如果同一個函式也以某種方式修改狀態（並且該修改在函式終止後持續），那麼該修改是一個副作用。

Clean Code 建議您避免副作用。

你的函式要麼改變物件的狀態，要麼返回一些資訊。一個函式不應該兩者兼得！

原則 7 - 使用異常，而不是錯誤程式碼

您的函式應該很少返回錯誤程式碼。相反，如果出現問題，您應該丟擲異常，並提供編寫良好的錯誤訊息。

錯誤程式碼的一個問題是它會導致深度巢狀的結構。當您返回錯誤程式碼時，呼叫者必須立即處理該錯誤程式碼。

另一方面，呼叫者可以將異常處理程式邏輯與其他程式碼分開（try、catch 語句具有單獨的 try 邏輯和 catch 邏輯）。