函数要多小才够好——谈小函数之道_时代站长

函数要多小才够好——谈小函数之道语言编程

来源：互联网 / 作者：SKY / 2018-11-26 22:39 / 点击：

设计良好的函数往往比较小，而过大函数的设计往往一塌糊涂，或者存在很大的优化空间。也许你认为讨论函数的大小没有必要，原因是函数设计的本质是内聚，它的大小只是它的表现形式。而上面的原因有必要让我们讨论一下函数的大小问题。我对函数的核心思路：

“设计良好的函数往往比较小，而过大函数的设计往往一塌糊涂，或者存在很大的优化空间。”

也许你认为讨论函数的大小没有必要，原因是函数设计的本质是内聚，它的大小只是它的表现形式。而上面的原因有必要让我们讨论一下函数的大小问题。

我对函数的核心思路：我提出代码最小处理单元的概念：一个基本操作（赋值，比较等），一个函数调用（包括调用后判断返回值进行判断）都看成一个最小处理单元。那么，一个函数，最小处理单元合理的个数范围在7以内。如果超过了7，你就要考虑把他们拆分成多个函数了（为什么是7？人同时能够处理的信息不超过7个）。

最小数目没有限制，即便是只有1个，也有存在的必要。

在下面的情况下我会将函数拆分为更小的函数：

1、一眼不能够看到函数所有的代码。

如果函数过长，无法一眼看到一个函数所有的代码，我会毫不犹豫的拆分。我不想让读者去翻屏，也不想让读者前顾后盼，顾此失彼。漂亮的函数应该让读者一眼就知道他在做什么以及怎么做的。

2、局部变量过多。

如果局部变量超过七个，我会考虑拆分函数。变量过多意味着我要记录太多的状态，这会加重我大脑的负担，同时要考虑太多的东西。这也同时意味着我可能没有对函数功能进行深入的思考。

3、太多的缩进。

太多的缩进意味着太多的嵌套，要么是循环，要么是判断，都会导致复杂的逻辑。

4、如果你在使用ctrl+c和ctrl+v

那你写的代码不够拽（DRY，Don’t Repeat Yourself）。这个时候，你要把你复制的部分拆分为新的函数。

5、不处于同一抽象层次。

举例，有一个初始化函数，需要初始化配置数据，套接字，数据库连接，通道状态。

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;

……

}

}

上个函数中对所有通道的初始化一块代码就和其他的不处于一个抽象层次，我们应该将它封装起来：

void chn_init（）

{

int i = 0;

for （i = 0;i < max_chn_num;i++）//初始化所有通道 {

G_user_chn［i］.status =status_init;

……

}

}

函数最小可以有多小，它存在的意义

我见过的最优秀的函数：

int max（int a， intb）

{

return a> b？a:b;

}

这个函数很小，只有一行，但是他存在的意义在于：在函数的调用点，我们一眼就知道是获取a和b中的最大值，而不是分析a > b?a:b的逻辑。这样可以节省程序员的脑力成本，从而达到一个目的：漂亮的函数应该让读者一眼就知道他在做什么以及怎么做的。

小函数的最大障碍：性能

对于程序员新手，小函数的最大障碍在于没有经验体会不到小函数的优势，没有经验拆分大函数为更小的函数。

对于有一定经验的程序员，小函数的最大障碍也许是对性能的忧虑。

对于性能，切记，不要过早优化。我们一般认为的程序的瓶颈，一般并不是程序的瓶颈：我们需要工具来确定真正的瓶颈所在，20%的代码耗费了80%的性能，优化之前首先要找到那20%的代码。函数调用会产生资源和性能的损耗，但是这是不是程序的性能瓶颈？消耗的性能占总体的性能百分比为多少？这一切在代码编写时并不清楚，所以，我的观点是宁可选择简短的函数来获得清晰简单的设计，以便在项目后期能够更快，更好的进行性能优化。

很多人都在质疑我上面列举的max函数的实例，如果说他在运行期间调用次数不大，则对性能的影响基本可以忽略，而获得的可读性，清晰性这极具价值；反过来，如果他的调用次数是否庞大，以致成为了性能的瓶颈，则完全可以在程序编写完成后，很快的用其他的方法优化。程序的瓶颈不会很多。

关于函数调用产生的性能消耗，我会抽时间测试一下，看到底占用多少。

最后的建议：

在对新员工培训的过程中，发现程序员新手一般对函数的大小不够敏感。所以，我建议你可以多尝试编写10行左右（甚至更小）的函数，慢慢你会发现小函数原来具有大威力。