與多數現代編程語言一樣，在 Python 中，函數是抽象和封裝的基本方法之一。你在開發階段或許已經寫過數百個函數，但并非每個函數都生而平等。寫出「糟糕的」函數會直接影響代碼的可讀性和可維護性。那么，什么樣的函數是「糟糕的」函數呢?更重要的是，要怎么寫出「好的」函數呢?

[[246148]]

簡單回顧

數學中充滿了函數，盡管我們可能記不住它們。首先來回憶一下大家最喜歡的話題——微積分。你可能記得這個方程式： f(x) = 2x + 3. 這是一個叫做「f」的函數，含有一個未知數 x，「返回」2*x+3。這個函數可能和我們在 Python 中看到的不一樣，但它的基本思想和計算機語言中的函數是一樣的。

函數在數學中歷史悠久，但在計算機科學中更加神通廣大。盡管如此，函數還是存在一些缺陷。接下來我們將討論一下什么是「好的」函數，以及在出現什么樣的征兆時我們需要重構函數。

決定函數好壞的關鍵

好的 Python 函數與蹩腳 Python 函數的區別是什么?「好」函數的定義之多讓人驚訝。從我們的目的出發，我會把好的 Python 函數定義為符合以下清單中大部分規則的函數(有些比較難實現)：

• 命名合理
• 具有單一功能
• 包含文檔注釋
• 返回一個值
• 代碼不超過 50 行
• 冪等，盡可能是純函數

對很多人來說，這個列表可能有些過于嚴格。但我保證，如果你的函數符合這些規則，你的代碼看起來會非常漂亮。下面我將分步講解各個規則，然后總結這些規則如何構成一個「好」函數。

命名

關于這個問題，我最喜歡的一句話(出自 Phil Karlton，總被誤以為是 Donald Knuth 說的)是：

在計算機科學中只有兩個難題：緩存失效和命名問題。

聽起來有點匪夷所思，但整個不錯的命名真的很難。下面就有一個糟糕的函數命名：

def get_knn(from_df): 

我基本上在任何地方都見過糟糕的命名，但這個例子來自數據科學(或者說，機器學習)，從業者總是在 Jupyter notebook 上寫代碼，然后嘗試將那些不同的單元變成一個可理解的程序。

該函數命名的第一個問題是使用首字母縮寫/縮略詞。比起縮略詞和并未普及的首字母縮寫，完整的英語單詞會更好。使用縮寫的唯一原因是為了節省打字時間，但現代的編輯器都有自動補全功能，所以你只需鍵入一次全名。之所以說縮寫是一個問題，是因為它們通常只能用于特定領域。在上面的代碼中，knn 是指「K-Nearest Neighbors」，df 指的是「DataFrame」——無處不在的 Pandas 數據結構。如果另外一個不太熟悉這些縮寫的編程人員正在閱讀代碼，那 TA 就會一頭霧水。

關于這個函數名稱，還有另外兩個小問題：單詞「get」無關緊要。對于大多數命名比較好的函數，很明顯函數會返回一些東西，其名字會反映這一點。from_df 也是不必要的。如果參數的名稱描述不夠清楚的話，函數的文檔注釋或者類型注釋將描述參數類型。

那我們如何重新命名這個函數呢?例如：

def k_nearest_neighbors(dataframe): 

現在，即使是外行也知道這個函數在計算什么了，參數的名稱(dataframe)也清楚地告訴我們應該傳遞什么類型的參數。

單一功能原則

「單一功能原則」來自 Bob Martin「大叔」的一本書，不僅適用于類和模塊，也同樣適用于函數(Martin 最初的目標)。該原則強調，函數應該具有「單一功能」。也就是說，一個函數應該只做一件事。這么做的一大原因是：如果每個函數只做一件事，那么只有在函數做那件事的方式必須改變時，該函數才需要改變。當一個函數可以被刪除時，事情就好辦了：如果其他地方發生改動，不再需要該函數的單一功能，那么只需將其刪除。

舉個例子來解釋一下。以下是一個不止做一件「事」的函數：

def calculate_and print_stats(list_of_numbers): 
 sumsum = sum(list_of_numbers)  
 mean = statistics.mean(list_of_numbers)  
 median = statistics.median(list_of_numbers)  
 mode = statistics.mode(list_of_numbers)  
 print('-----------------Stats-----------------')  
 print('SUM: {}'.format(sum) print('MEAN: {}'.format(mean) 
 print('MEDIAN: {}'.format(median)  
 print('MODE: {}'.format(mode) 

這一函數做兩件事：計算一組關于數字列表的統計數據，并將它們打印到 STDOUT。該函數違反了只有一個原因能讓函數改變的原則。顯然有兩個原因可以讓該函數做出改變：新的或不同的數據需要計算或輸出的格式需要改變。最好將該函數寫成兩個獨立的函數：一個用來執行并返回計算結果;另一個用來接收結果并將其打印出來。函數有多重功能的一個致命漏洞是函數名稱中含有單詞「and」

這種分離還可以簡化針對函數行為的測試，而且它們不僅被分離成一個模塊中的兩個函數，還可能在適當情況下存在于不同的模塊中。這使得測試更加清潔、維護更加簡單。

只做兩件事的函數其實非常罕見。更常見的情況是一個函數負責許多許多任務。再次強調一下，為可讀性、可測試性起見，我們應該將這些「多面手」函數分成一個一個的小函數，每個小函數只負責一項任務。

文檔注釋

很多 Python 開發者都知道 PEP-8，它定義了 Python 編程的風格指南，但很少有人了解定義了文檔注釋風格的 PEP-257。在這里并不會詳細介紹 PEP-257，讀者可詳細閱讀該指南所約定的文檔注釋風格。

• PEP-8：https://www.python.org/dev/peps/pep-0008/
• PEP-257：https://www.python.org/dev/peps/pep-0257/

首先文檔注釋是在定義模塊、函數、類或方法的第一段字符串聲明，這一段字符串應該需要描述清楚函數的作用、輸入參數和返回參數等。PEP-257 的主要信息如下：

• 每一個函數都需要一個文檔描述;
• 使用合適的語法和標點，書寫完整的句子;
• 最開始需要用一句話總結函數的主要作用;
• 使用規定性的語言而不是描述性的語言。

在編寫函數時，遵循這些規則很容易。我們只需要養成編寫文檔注釋的習慣，并在實際寫函數主體之前完成它們。如果你不能清晰地描述這個函數的作用是什么，那么你需要更多地考慮為什么要寫這個函數。

返回值

函數可以且應該被視為一個獨立的小程序。它們以參數的形式獲取一些輸入，并返回一些輸出值。當然，參數是可選的，但是從 Python 內部機制來看，返回值是不可選的。即使你嘗試創建一個不會返回值的函數，我們也不能選擇不在內部采用返回值，因為 Python 的解釋器會強制返回一個 None。不相信的讀者可以用以下代碼測試：

❯ python3 
Python 3.7.0 (default, Jul 23 2018, 20:22:55) 
[Clang 9.1.0 (clang-902.0.39.2)] on darwin 
Type "help", "copyright", "credits" or "license" *for *more information. 
>>> def add(a, b): 
... print(a + b) 
... 
>>> b = add(1, 2) 
3 
>>> b 
>>> b is None 
True 

運行上面的代碼，你會看到 b 的值確實是 None。所以即使我們編寫一個不包含 return 語句的函數，它仍然會返回某些東西。不過函數也應該要返回一些東西，因為它也是一個小程序。沒有輸出的程序又會有多少用，我們又如何測試它呢?

我甚至希望發表以下聲明：每一個函數都應該返回一個有用的值，即使這個值僅可用來測試。我們寫的代碼應該需要得到測試，而不帶返回值的函數很難測試它的正確性，上面的函數可能需要重定向 I/O 才能得到測試。此外，返回值能改變方法的調用，如下代碼展示了這種概念：

with open('foo.txt', 'r') as input_file: 
 for line in input_file: 
 if line.strip().lower().endswith('cat'): 
 # ... do something useful with these lines 

代碼行 if line.strip().lower().endswith('cat') 能夠正常運行，因為字符串方法 (strip(), lower(), endswith()) 會返回一個字符串以作為調用函數的結果。

以下是人們在被問及為什么他們寫的函數沒有返回值時給出的一些常見原因：

我并不同意這種觀點，因為在操作成功完成時，函數可以返回 True。

當然也可以返回包含多個值的一個元組。簡而言之，即使在現有的代碼庫中，從函數返回一個值肯定是一個好主意，并且不太可能破壞任何東西。

函數長度

函數的長度直接影響了可讀性，因而會影響可維護性。因此要保證你的函數長度足夠短。50 行的函數對我而言是個合理的長度。

如果函數遵循單一功能原則，一般而言其長度會非常短。如果函數是純函數或冪等函數(下面會討論)，它的長度也會較短。這些想法對于構造簡潔的代碼很有幫助。

那么如果一個函數太長該怎么辦?代碼重構(refactor)!代碼重構很可能是你寫代碼時一直在做的事情，即使你對這個術語并不熟悉。它的含義是：在不改變程序行為的前提下改變程序的結構。因此從一個長函數提取幾行代碼并轉換為屬于該函數的函數也是一種代碼重構。這也是將長函數縮短最快和最常用的方法。只要適當給這些新函數命名，代碼的閱讀將變得更加容易。

冪等性和函數純度

冪等函數(idempotent function)在給定相同變量參數集時會返回相同的值，無論它被調用多少次。函數的結果不依賴于非局部變量、參數的易變性或來自任何 I/O 流的數據。以下的 add_three(number) 函數是冪等的：

def add_three(number): 
 """Return *number* + 3.""" 
 return number + 3 

無論何時調用 add_three(7)，其返回值都是 10。以下展示了非冪等的函數示例：

def add_three(): 
 """Return 3 + the number entered by the user.""" 
 number = int(input('Enter a number: ')) 
 return number + 3 

這函數不是冪等的，因為函數的返回值依賴于 I/O，即用戶輸入的數字。每次調用這個函數時，它都可能返回不同的值。如果它被調用兩次，則用戶可以第一次輸入 3，第二次輸入 7，使得對 add_three() 的調用分別返回 6 和 10。

為什么冪等很重要?

可測試性和可維護性。冪等函數易于測試，因為它們在使用相同參數的情況下會返回同樣的結果。測試就是檢查對函數的不同調用所返回的值是否符合預期。此外，對冪等函數的測試很快，這在單元測試(Unit Testing)中非常重要，但經常被忽視。重構冪等函數也很簡單。不管你如何改變函數以外的代碼，使用同樣的參數調用函數所返回的值都是一樣的。

什么是「純」函數?

在函數編程中，如果函數是冪等函數且沒有明顯的副作用(side effect)，則它就是純函數。記住，冪等函數表示在給定參數集的情況下該函數總是返回相同的結果，不能使用任何外部因素來計算結果。但是，這并不意味著冪等函數無法影響非局部變量(non-local variable)或 I/O stream 等。例如，如果上文中 add_three(number) 的冪等版本在返回結果之前先輸出了結果，它仍然是冪等的，因為它訪問了 I/O stream，這不會影響函數的返回值。調用 print() 是副作用：除返回值以外，與程序或系統中其余部分的交互。

我們來擴展一下 add_three(number) 這個例子。我們可以用以下代碼片段來查看 add_three(number) 函數被調用的次數：

add_three_calls = 0 
def add_three(number): 
 """Return *number* + 3.""" 
 global add_three_calls 
 print(f'Returning {number + 3}') 
 add_three_calls += 1 
 return number + 3 
def num_calls(): 
 """Return the number of times *add_three* was called.""" 
 return add_three_calls 

現在我們向控制臺輸出結果(一項副作用)，并修改了非局部變量(又一項副作用)，但是由于這些副作用不影響函數的返回值，因此該函數仍然是冪等的。

純函數沒有副作用。它不僅不使用任何「外來數據」來計算值，也不與系統/程序的其它部分進行交互，除了計算和返回值。因此，盡管我們新定義的 add_three(number) 仍是冪等函數，但它不再是純函數。

純函數不記錄語句或 print() 調用，不使用數據庫或互聯網連接，不訪問或修改非局部變量。它們不調用任何其它的非純函數。

總之，純函數無法(在計算機科學背景中)做到愛因斯坦所說的「幽靈般的遠距效應」(spooky action at a distance)。它們不以任何形式修改程序或系統的其余部分。在命令式編程中(寫 Python 代碼就是命令式編程)，它們是最安全的函數。它們非常好測試和維護，甚至在這方面優于純粹的冪等函數。測試純函數的速度與執行速度幾乎一樣快。而且測試很簡單：沒有數據庫連接或其它外部資源，不要求設置代碼，測試結束后也不需要清理什么。

顯然，冪等和純函數是錦上添花，但并非必需。即，由于上述優點，我們喜歡寫純函數或冪等函數，但并不是所有時候都可以寫出它們。關鍵在于，我們本能地在開始部署代碼的時候就想著剔除副作用和外部依賴。這使得我們所寫的每一行代碼都更容易測試，即使并沒有寫純函數或冪等函數。

總結

寫出好的函數的奧秘不再是秘密。只需按照一些完備的最佳實踐和經驗法則。希望這篇文章能夠幫助到大家。

原文鏈接：https://hackernoon.com/write-better-python-functions-c3a9a36382a6

【本文是51CTO專欄機構“機器之心”的原創譯文，微信公眾號“機器之心( id: almosthuman2014)”】

戳這里，看該作者更多好文