函式要多小才夠好談小函式之道

「設計良好的函式往往比較小，而過大函式的設計往往一塌糊塗，或者存在很大的優化空間。」

也許你認為討論函式的大小沒有必要，原因是函式設計的本質是內聚，它的大小只是它的表現形式。而上面的原因有必要讓我們討論一下函式的大小問題。

我對函式的核心思路：我提出**最小處理單元的概念：乙個基本操作（賦值，比較等），乙個函式呼叫（包括呼叫後判斷返回值進行判斷）都看成乙個最小處理單元。那麼，乙個函式，最小處理單元合理的個數範圍在7以內。如果超過了7，你就要考慮把他們拆分成多個函式了（為什麼是7？人同時能夠處理的資訊不超過7個）。

最小數目沒有限制，即便是只有1個，也有存在的必要。

在下面的情況下我會將函式拆分為更小的函式：

如果函式過長，無法一眼看到乙個函式所有的**，我會毫不猶豫的拆分。我不想讓讀者去翻屏，也不想讓讀者前顧後盼，顧此失彼。漂亮的函式應該讓讀者一眼就知道他在做什麼以及怎麼做的。

如果區域性變數超過七個，我會考慮拆分函式。變數過多意味著我要記錄太多的狀態，這會加重我大腦的負擔，同時要考慮太多的東西。這也同時意味著我可能沒有對函式功能進行深入的思考。

太多的縮排意味著太多的巢狀，要麼是迴圈，要麼是判斷，都會導致複雜的邏輯。

舉例，有乙個初始化函式，需要初始化配置資料，套接字，資料庫連線，通道狀態。

void init()
}

上個函式中對所有通道的初始化一塊**就和其他的不處於乙個抽象層次，我們應該將它封裝起來：

void chn_init()
}

函式最小可以有多小，它存在的意義

我見過的最優秀的函式：

int max(int a, intb)

這個函式很小，只有一行，但是他存在的意義在於：在函式的呼叫點，我們一眼就知道是獲取a和b中的最大值，而不是分析a > b?a:b的邏輯。這樣可以節省程式設計師的腦力成本，從而達到乙個目的：漂亮的函式應該讓讀者一眼就知道他在做什麼以及怎麼做的。

在對新員工培訓的過程中，發現程式設計師新手一般對函式的大小不夠敏感。所以，我建議你可以多嘗試編寫10行左右（甚至更小）的函式，慢慢你會發現小函式原來具有大威力。

設計良好的函式往往比較小，而過大函式的設計往往一塌糊塗，或者存在很大的優化空間。也許你認為討論函式的大小沒有必要，原因是函式設計的本質是內聚，它的大小只是它的表現形式。而上面的原因有必要讓我們討論一下函式的大小問題。我對函式的核心思路我提出最小處理單元的概念乙個基本操作賦值，比較等乙個函式...

同步於我的csdn部落格也許你認為討論函式的大小沒有必要，原因是函式設計的本質是內聚，它的大小只是它的表現形式。而上面的原因有必要讓我們討論一下函式的大小問題。我對函式的核心思路我提出最小處理單元的概念乙個基本操作賦值，比較等乙個函式呼叫包括呼叫後判斷返回值進行判斷都看成乙個最小處理...

函式要多小才夠好 談小函式之道