“設(shè)計(jì)良好的函數(shù)往往比較小，而過(guò)大函數(shù)的設(shè)計(jì)往往一塌糊涂，或者存在很大的優(yōu)化空間。”

也許你認(rèn)為討論函數(shù)的大小沒(méi)有必要，原因是函數(shù)設(shè)計(jì)的本質(zhì)是內(nèi)聚，它的大小只是它的表現(xiàn)形式。而上面的原因有必要讓我們討論一下函數(shù)的大小問(wèn)題。

我對(duì)函數(shù)的核心思路：我提出代碼最小處理單元的概念：一個(gè)基本操作（賦值，比較等），一個(gè)函數(shù)調(diào)用（包括調(diào)用后判斷返回值進(jìn)行判斷）都看成一個(gè)最小處理單元。那么，一個(gè)函數(shù)，最小處理單元合理的個(gè)數(shù)范圍在7以?xún)?nèi)。如果超過(guò)了7，你就要考慮把他們拆分成多個(gè)函數(shù)了（為什么是7？人同時(shí)能夠處理的信息不超過(guò)7個(gè)）。

最小數(shù)目沒(méi)有限制，即便是只有1個(gè)，也有存在的必要。

在下面的情況下我會(huì)將函數(shù)拆分為更小的函數(shù)：

1、一眼不能夠看到函數(shù)所有的代碼。

如果函數(shù)過(guò)長(zhǎng)，無(wú)法一眼看到一個(gè)函數(shù)所有的代碼，我會(huì)毫不猶豫的拆分。我不想讓讀者去翻屏，也不想讓讀者前顧后盼，顧此失彼。漂亮的函數(shù)應(yīng)該讓讀者一眼就知道他在做什么以及怎么做的。

2、局部變量過(guò)多。

如果局部變量超過(guò)七個(gè)，我會(huì)考慮拆分函數(shù)。變量過(guò)多意味著我要記錄太多的狀態(tài)，這會(huì)加重我大腦的負(fù)擔(dān)，同時(shí)要考慮太多的東西。這也同時(shí)意味著我可能沒(méi)有對(duì)函數(shù)功能進(jìn)行深入的思考。

3、太多的縮進(jìn)。

太多的縮進(jìn)意味著太多的嵌套，要么是循環(huán)，要么是判斷，都會(huì)導(dǎo)致復(fù)雜的邏輯。

4、如果你在使用Ctrl+C和Ctrl+V

那你寫(xiě)的代碼不夠拽（DRY，Don't Repeat Yourself）。這個(gè)時(shí)候，你要把你復(fù)制的部分拆分為新的函數(shù)。

5、不處于同一抽象層次。

舉例，有一個(gè)初始化函數(shù)，需要初始化配置數(shù)據(jù)，套接字，數(shù)據(jù)庫(kù)連接，通道狀態(tài)。

Void init()    
{    
        Config_init();    
        Socket_init();    
        Db_init();    
        Int I = 0;    
        For (I = 0;I < max_chn_num;i++)//初始化所有通道    
        {    
                G_user_chn[i].status = status_init;    
                ……    
         }    
}   

上個(gè)函數(shù)中對(duì)所有通道的初始化一塊代碼就和其他的不處于一個(gè)抽象層次，我們應(yīng)該將它封裝起來(lái)：

void chn_init()    
{    
        Int I = 0;    
        For (I = 0;I < max_chn_num;i++)//初始化所有通道    
        {    
                G_user_chn[i].status =status_init;    
                ……    
        }    
}   

函數(shù)最小可以有多小，它存在的意義

我見(jiàn)過(guò)的最優(yōu)秀的函數(shù)：

int max(int a, int b)    
{    
        return a > b ? a : b;    
}   

這個(gè)函數(shù)很小，只有一行，但是他存在的意義在于：在函數(shù)的調(diào)用點(diǎn)，我們一眼就知道是獲取a和b中的最大值，而不是分析 a>b?a:b 的邏輯。這樣可以節(jié)省程序員的腦力成本，從而達(dá)到一個(gè)目的：漂亮的函數(shù)應(yīng)該讓讀者一眼就知道他在做什么以及怎么做的。

小函數(shù)的最大障礙：性能

對(duì)于程序員新手，小函數(shù)的最大障礙在于沒(méi)有經(jīng)驗(yàn)體會(huì)不到小函數(shù)的優(yōu)勢(shì)，沒(méi)有經(jīng)驗(yàn)拆分大函數(shù)為更小的函數(shù)。

對(duì)于有一定經(jīng)驗(yàn)的程序員，小函數(shù)的最大障礙也許是對(duì)性能的憂(yōu)慮。

對(duì)于性能，切記，不要過(guò)早優(yōu)化。我們一般認(rèn)為的程序的瓶頸，一般并不是程序的瓶頸：我們需要工具來(lái)確定真正的瓶頸所在，20%的代碼耗費(fèi)了80%的性能，優(yōu)化之前首先要找到那20%的代碼。函數(shù)調(diào)用會(huì)產(chǎn)生資源和性能的損耗，但是這是不是程序的性能瓶頸？消耗的性能占總體的性能百分比為多少？這一切在代碼編寫(xiě)時(shí)并不清楚，所以，我的觀點(diǎn)是寧可選擇簡(jiǎn)短的函數(shù)來(lái)獲得清晰簡(jiǎn)單的設(shè)計(jì)，以便在項(xiàng)目后期能夠更快，更好的進(jìn)行性能優(yōu)化。

很多人都在質(zhì)疑我上面列舉的max函數(shù)的實(shí)例，如果說(shuō)他在運(yùn)行期間調(diào)用次數(shù)不大，則對(duì)性能的影響基本可以忽略，而獲得的可讀性，清晰性這極具價(jià)值；反過(guò)來(lái)，如果他的調(diào)用次數(shù)是否龐大，以致成為了性能的瓶頸，則完全可以在程序編寫(xiě)完成后，很快的用其他的方法優(yōu)化。程序的瓶頸不會(huì)很多。

關(guān)于函數(shù)調(diào)用產(chǎn)生的性能消耗，我會(huì)抽時(shí)間測(cè)試一下，看到底占用多少。

最后的建議：

在對(duì)新員工培訓(xùn)的過(guò)程中，發(fā)現(xiàn)程序員新手一般對(duì)函數(shù)的大小不夠敏感。所以，我建議你可以多嘗試編寫(xiě)10行左右（甚至更?。┑暮瘮?shù)，慢慢你會(huì)發(fā)現(xiàn)小函數(shù)原來(lái)具有大威力。

原文鏈接：http://kb.cnblogs.com/page/154245/

【編輯推薦】

1. 函數(shù)式編程如何才有一席之地
2. 8月編程語(yǔ)言排行榜：C語(yǔ)言助力火星登陸
3. 沒(méi)有完美的軟件：編程永遠(yuǎn)不容易
4. Rob Pike：我得到的最有價(jià)值的編程建議
5. 最有價(jià)值的編程忠告（來(lái)自貝爾實(shí)驗(yàn)室Plan 9操作系統(tǒng)的創(chuàng)始人Rob Pike）