提高代碼品質：如何編寫函數

函數是實作程式功能的最基本機關，每一個程式都是由一個個最基本的函數構成的。寫好一個函數是提高程式代碼品質最關鍵的一步。本文就函數的編寫，從函數命名，代碼分布，技巧等方面入手，談談如何寫好一個可讀性高、易維護，易測試的函數。

首先從命名說起，命名是提高可讀性的第一步。如何為變量和函數命名一直是開發者心中的痛點之一，對于母語非英語的我們來說，更是難上加難。下面我來說說如何為函數命名的一些想法和感受：

在談及如何為函數取一個準确而優雅的名字之前，首先最重要的是要有統一的命名規則。這是提高代碼可讀性的最基礎的準則。

帕斯卡命名法和駝峰命名法是目前比較流行的兩種規則，不同語言采用的規則可能不一樣，但是要記住一點：保持團隊和個人風格一緻。

1、帕斯卡命名法

帕斯卡命名法簡單地說就是：多個單詞組成一個名稱時，每個單詞的首字母大寫。比如：

在C#中，這種命名法常用于類、屬性，函數等等，在js中，構造函數也推薦采用這種方式命名。

2、駝峰命名法

駝峰命名法和帕斯卡命名法很類似，多個單詞組成一個名稱時，第一個單詞全部小寫，後面單詞首字母大寫。比如：

駝峰命名法一般用于字段、局部變量、函數參數等等。，在js中，函數也常用此方法命名。

采用哪種命名規則并不絕對，最重要的是要遵守團隊約定，語言規範。

有的開發者可能覺得相較于長函數名來說，短函數名看起來可能更簡潔，看起來也更舒服。但是通常來說，函數名稱越短其描述的意思越抽象。函數使用者對函數的第一印象就是函數名稱，進而了解函數的功能，我們應該盡可能地描述到函數所做的所有事情，防止使用者不知道或誤解造成潛在的錯誤。

舉個例子，假設我們做一個添加評論的功能，添加完畢後并傳回評論總數量，如何命名比較合适呢？

這隻是簡單的一個例子，實際開發中可能會遇到得更多複雜的情況，單一職責原則是我們開發函數要遵守的準則，但是有時候無法做到函數單一職責時，請記得函數名應該盡可能地描述所有事情。當你無法命名一個函數時，應該分析一下，這個函數的編寫是否科學，有什麼辦法可以去優化它。

這一點對母語非英語的開發者來說應該是比較難的一點，想要提高這方面的能力，最主要的還是要提高詞彙量，多閱讀優秀代碼積累經驗。

這裡簡單說說我自己的一些感想和看法：

1、不要采用太抽象廣泛的單詞

很多開發人員會采用一個比較寬泛的動詞來為函數命名，最典型的一個例子就是get這個單詞。我們平時開發中經常會通過各種不同的方式拿到資料，但是每一種方式都用get就有點太抽象了。具體如何命名，要具體分析：

（1）簡單的傳回資料

（2）從遠端擷取資料

（3）從本地存儲加載資料

（4）通過計算擷取資料

（5）從數組中查找資料

（6）從一些資料生成或得到

這是一個簡單的例子，我們平時開發中遇到的情況肯定會複雜得多，關鍵還是靠單詞的積累，多閱讀優秀源碼

下面是整理的一些常用的對仗詞，大家可以參考使用

這一點也是很重要的，尤其是在團隊合作中，不同的項目和需求可能導緻的不同的命名規則。

比如我們通常采用的命名規則是動賓結構，也就是動詞在前，名詞災後。但是有一些項目，比如資料接口等項目中，有的團隊會采用名字在前，動詞在後的形式，例如：

這種的好處是看到前面的名詞，比如ProductsGet，就能很快的知道這是産品相關的資料接口。

當然這個并不是絕對的，關鍵還是要團隊共同制定和遵守同一套命名規則。

函數使用者在調用函數時，必須嚴格遵守函數定義的參數，這對函數的易用性，可測試性等方面都是至關重要的。下面我從幾個方面來談談關于如何優化好函數參數的一些想法。

毫無疑問，函數參數越多，函數的易用性就越差，因為使用者需要嚴格眼中參數清單依次輸入參數，如果某個參數輸錯，将導緻不可意料的結果。

但是，函數參數就一定越少越好嗎？我們來看看下面的例子：

在這個例子中，我們通過calculatePrice這個函數來計算價格，函數不接收任何參數，直接通過兩個全局變量unitPrice和count進行計算。這種函數的定義對使用者來說非常友善，直接調用即可，不用輸入任何參數。但是這裡可能會有潛在的bug：全局變量可能在其他地方被修改成其他值了，難以進行單元測試等等問題。是以，這個函數可以傳入數量和價格資訊：

這種方式下，函數使用者在使用時，要傳入參數進行調用，避免了全局變量可能存在的問題。另外也降低了耦合，提高了可測試性，在測試的時候就不必依賴于全局變量。

當然，在保證函數不依賴于全局變量和測試性的情況下，函數參數還是越少越好。《代碼大全》中提出将函數的參數限制在7個以内，這個可以作為我們的參考。

有的時候，我們不可避免地要使用超過10個以上函數，在這中情況下，我們可以考慮将類似的參數構造成一個類，我們來看看一個典型的例子。

我相信大家平時一定做過這樣的功能，清單篩選，其中涉及到各種條件的篩選，排序，分頁等等功能，如果将參數一個一個地列出來必定會很長，例如：

這是一個篩選酒店的函數，其中的參數分别是城市，入住和退房時間，價格，星級，位置，是否有wifi，是否有早餐，排序，頁碼等等，實際的情況可能會更多。在這種參數特别多的情況下，我們可以考慮将一些相似的參數提取成類出來：

将多個參數提取成對象了，雖然對象數量增多了，但是函數參數更清晰了，調用起來也更友善了。

有的時候，我們會寫出使用bool作為參數的情況，比如：

如果沒有注釋，使用者看到這樣的代碼：getProduct(true)，他肯定搞不清楚true是代表什麼意思，還要去檢視函數定義才能明白這個函數是如何使用的。這就意味着這個函數不夠清晰，就應該考慮去優化它。通常有兩種方式去優化它：

（1）将函數一分為二，分成兩個函數getFinishedProduct和getUnFinishedProduct

（2）将bool轉換成有意義的枚舉getProduct(ProductStatus)

如果輸入參數在函數内被修改了，很有可能造成潛在的bug，而且使用者不知道調用函數後居然會修改函數參數。

正确使用輸入參數的做法應該是隻傳入參數用于函數調用。

如果不可避免地要修改，一定要在注釋中說明。

使用輸出參數說明這個函數不隻做了一件事情，而且使用者使用的時候可能還會感到困惑。正确的方式應該是分解函數，讓函數隻做一件事。

函數體就是實作函數功能的整個邏輯，是一個函數最關鍵的地方。下面我談談關于函數代碼編寫的一些個人想法。

有的時候，我們會在一個函數内進行一系列的操作來完成一個功能，比如：

這段代碼計算了房間價格和早餐價格，然後将兩者相加傳回總價格。

這段代碼乍一看，沒有什麼問題，但是我們分析代碼，我們先是分别擷取了房間數量和早餐數量，然後再通過房間數量和早餐數量分别計算兩者的價格。這種情況下，房間數量和計算房間價格的代碼分散在了兩個位置，早餐價格的計算也是分散到了兩個位置。也就是兩部分相關的代碼分散在了各處，這樣閱讀起代碼來邏輯會略顯不通，代碼組織不夠好。我們應該讓相關的語句和操作放在一起，也有利于重構代碼。我們修改如下：

我們将相關的操作放在一起，這樣代碼看起來更清晰了，而且也更容易重構了。

我們平時寫if，switch或for語句是常有的事兒，也一定寫過多層if或for語句嵌套的情況，如果代碼裡的嵌套超過3層，閱讀起來就會非常困難了。我們應該盡量避免代碼嵌套多層，最好不要超過2層。下面我來說說我平時一些減少嵌套的技巧或方法。

多層if語句嵌套是常有的事情，有什麼好的方法可以減少嵌套呢？

1、盡早終止函數或傳回資料

如果符合某個條件下可以直接終止函數，則應該将這個條件放在第一位。我們來看看下面的例子。

這段代碼中if語句嵌套了3層，看起來已經很複雜了，我們可以将最後面的return提取到最前面去。

這段代碼中，我們把condition1等于false的語句提取到前面，直接終止函數，将多層嵌套的if語句重構成隻有一層if語句，代碼也更清晰了。

注意：一般情況下，我們寫if語句會将條件為true的情況寫在前面，這也比較符合我們的思維習慣。如果是多層嵌套的情況，應該優先減少if語句的嵌套

2、不适用if語句或switch語句

條件語句一般來說是不可避免的，有的時候，我們要判斷很多條件就會寫很多if-elseif語句，嵌套的話，就更加麻煩了。如果有一天增加了新需求，我們就要去增加一個if分支語句，這樣不僅修改起來麻煩，而且容易出錯。《代碼大全》提出的表驅動法可以有效地解決if語句帶來的問題。我們來看下面這個例子：

這段代碼分别依次判斷了四種情況，如果再增加一種情況，我們就要再新增一個if分支，這樣就可能造成潛在的問題，如何去優化這段代碼呢？我們可以采用一個Map或Dictionary來将每一種情況和相應值一一對應。

通過map優化後，整個代碼不僅更加簡潔，修改起來也更友善而且不易出錯了。

當然，很多時候我們的條件判斷語句并不是這麼簡單的，可能會涉及到複雜的邏輯運算，大家可以檢視《代碼大全》第18章，其中有詳細的介紹。

3、提取内層嵌套為一個函數進行調用

多層嵌套的時候，我們還可以将内層嵌套提取到一個新的函數中，然後調用該函數，這樣代碼也就更清晰了。

for循環嵌套相比于if嵌套來說更加複雜，閱讀起來會更麻煩，下面說說幾點要注意的東西：

1、最多隻能兩層for循環嵌套

2、提取内層循環到新函數中

3、多層循環時，不要簡單地位索引變量命名為i，j，k等，容易造成混淆，要有具體的意思

有的時候，我們會寫出一些比較複雜的邏輯，閱讀代碼的人看到後可能搞不清楚要做什麼，這個時候，就應該提取出這段複雜的邏輯代碼。

這段代碼表示當年齡大于18并且是男性的話，可以doSth，但是還是不夠清晰，可以将其提取出來

雖說多了一個函數，但是代碼更加清晰和語義化了。

本文從函數命名，函數參數和函數的代碼編寫三個方面談了關于如何編寫好一個函數的感受和想法。文中提到了很多具體的情況，當然日常編碼中肯定會遇到更多複雜的情況可能我暫時沒有想到。我簡單的歸納了幾點：

1、準确地對變量、函數命名

2、不要有重複邏輯的代碼

3、函數的行數不要超過20行，這裡的20行隻是個大概，并不一定是這個數字

4、減少嵌套

我相信大家一定會很多關于這方面的經驗，歡迎進行交流，共同提高代碼品質。