函数的意义

coding style 专栏收录该内容
8 篇文章 0 订阅

问题背景:

A:这个函数的圈复杂度降不下去了,只能这样了
B:现在的圈复杂度是多少?
A:17
B:这么高,怎么会降不了?
A:要拆函数也可以拆,只是不想拆出那么多没意义的函数。

问题描述:

怎样的函数才算是有意义的函数?
比如这样的函数有没有意义?
(1)只被调用一次的函数
(2)只有一句实现内容的函数
(3)函数很多的参数
比如一个函数,有很多局部变量,如果要拆成多个函数,那么每个函数都要传递这些局部变量,会造成函数的参数很多。

在直接回答这个问题之前,先分析一下把一个大函数拆分多个小函数的优点与缺点。

拆分函数的优点:

(1)抽象级上的封装,一个函数里的所有语句都是同一个抽象级的
(2)相关概念的封装,一个函数里的所有语句都是为了做同一件事,达到同一个目的
(3)不相关概念的区分,不同的事分别放在不同的函数里,改名相互干扰
(4)让代码更易阅读
总结:读得方便

拆分函数的缺点:

(1)加一个函数麻烦,又只被调用一次,写得不值
(2)写得时候需要跳跃思考
第一遍写代码时,常常是想到哪就写到哪,不管是业务逻辑还是算法细节,都是按照执行顺序一步一步地往下写
但拆分函数时,不是按照执行顺序去思考代码的,而是按照抽象级去思考代码的。
(3)函数调用开销
这通常是最次要的原因,几乎可以忽略
(4)代码相关耦合性太高,难以拆分
就像《问题描述》中的(3)
(5)拆分函数又要考虑起名字的问题
总结:写得不方便

回到前面的问题:

一个函数到底有没有意义,说到底就是写得方便与读得方便的权衡问题。
怎样权衡呢,这里以数组与链表的区别为例。
数组和链表都是线性结构的数据组织方式,究竟哪种方式更好呢?
应该说各有各的优缺点。数组方式相对链表来说读效率高O(1),写效率低O(n)。链表方式相对数组方式来说,读效率低O(n/2),写效率高O(n/2)。
在实际应用中,以读为主的实现通常用数组,以写为组的实现通过用链表。
在拆分函数这个问题上,我们要考虑我们在开发过程中,是以写为主?还是以读为主?
Uncle Bob刚好在这方便做过一些统计,他发现,即使是在开发过程中,大部分时间也是在读代码的。
那么更何况后期维护,即使是修改代码,也是要以读懂代码为基础的。
很显然,我们的开发是以读为主的,因此,便于阅读的代码就是有意义的代码。适当地牺牲“写的方便性”来实现“读的方便性”是有必要的。

就事论事:

(1)只被调用一次的函数是否有意义?
答:如果它有助于阅读,就是有意义的,比如init();
(2)只有一句实现内容的函数是否有意义?
答:如果它有助于阅读,就是有意义的,比如将多个判断条件合并
(3)有很参数的函数是否有意义?
答:如果“读得方便”的代价是“写得很不方便”,这并不意味着它不应该被拆分。而是说明这个函数本身设计不合理。它不只要被拆分,更要被重构。

怎样让函数变成有意义:

(1)在第一次写代码时,常常是跟着灵感走,所以会写得杂乱无章,如果用TDD会好一点
(2)即使在写的时候没有TDD,最终也是要把UT补全的。
(3)有了UT,就可以放心大胆地重构,这是一个很大的话题

哪些代码可以拆分?

(1)函数缩进达到3级。(假设一开始是1级)
(2)函数长度超过12行
(3)几乎相似的代码出现了3遍
(4)判断条件3个以上
(5)函数参数3个以上
(6)不得不使用注释
(7)代码逻辑明显分成几块
  • 0
    点赞
  • 1
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值