函数要多小才够好——谈小函数之道

来源:常高伟的博客

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

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

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

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

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

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

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

2、局部变量过多。

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

3、太多的缩进。

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

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

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

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

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

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

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

我见过的最优秀的函数:

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

函数要多小才够好——谈小函数之道

小函数的最大障碍:性能

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

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

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

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

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

最后的建议:

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

 

收藏 11 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 在面向对象语言中,可以借助private将辅助函数隐世,不过像c这类非面向对象的语言,过多的函数是反而让人眼花缭乱吧。不妥之处还请指正。

    • ninja   2013/12/21

      就算是面向对象的,比如我用的java我感觉写太多函数也会傻掉的。特别是文中的不超过7个最小单元,如果严格按照这样执行,我肯定没几次能够按时交货的,毕竟给函数起名想参数之类的事并不是那么简单的

      • 威老   2015/01/16

        难道还得给你写另外一篇文章:《类要多小才够好----谈小类之道》

  • 函数调函数,不知道多了的时候,异常是怎么处理的,调试的方便性考虑。

  • 这样会不会导致函数太多

  • 性能瓶颈需要使用工具来确定,而不是拍脑袋想出来的。

  • fuyonggao   2013/07/31

    max函数和小函数是两码事
    如果有人用max来解决问题,那么他就不应该当程序员
    add(a,b) ==>a+b 是没必要的,孔乙己写茴字而已

    • iyuan   2013/08/02

      有意义的吧,只是这里的例子简单,只是2个数字的比较,如果是多个数字,甚至是未知长度的数字呢?当然,具体还是要看应用场景的。作者这里更多的应该是强调一种写小函数的习惯。

  • G   2013/08/02

    上面几位也说到关键点了,你的函数太多,也会增加你的心智负担.还有,人同时能够处理的信息不超过7个,这个貌似也不太准确,是瞬间记忆一般能记住7个,而真正同时处理信息的时候,7个,压力真的很大

  • ljf10000   2013/08/03

    大量小函数增加心智负担?不认同。

    一般而言,小函数主要用在(1)公共封装(2)模块内部辅助函数
    公共封装,比如skbuffer,封装的小函数很多,但很清晰;反之,如果不封装,大家八仙过海、各显其能,那绝对是噩梦。
    内部辅助函数,相信作为一个模块负责人,宁愿维护100个小函数、每个小函数不超过30行的模块,也不愿意维护30个大函数、每个函数超过100行的模块;当然,你非要说就喜欢千行以上的函数,那你是上帝。

跳到底部
返回顶部