1

大多数人都会说，java方法不能太长，但也不能定死，要具体问题具体分析。

再追问一下，有人会说，不超过200行，100行，50行，30行都有。

另有人说，面向对象风格的可以短些，面向过程风格的可以长些。

也有人说，一个方法不超过一屏幕就行(姑且不论显示器大小，字体大小和分辨率问题)。

先摘录一段Martin Fowler《重构》P110-P111 中的一段话：

人们有时会问我，一个函数多长才合适?

在我看来，长度不是问题，关键在于函数名称和函数本体之间的语义距离(semantic distance)。

如果提炼动作(extracting)可以强化代码的清晰度，那就去做，就算函数名称比提炼出来的代码还长也无所谓。

说了直白点，函数名是干什么，函数体是怎么干。

当 2 者不是那么能容易分辨出来时，就需要提炼出函数来，让代码更好懂。

既然大师都说了，长度不是问题了吗，那干嘛还要追究函数长度规范呢?

其实大师讲的是对于懂得编程之道的人而言，不用关心长度，因为小函数是必然的结果。

但在开发实践中，适当的函数长度限制值，可以给予我们警示，为什么这个方法写长了?哪里不对劲了?

对于这个问题我的回答是：Java函数不应超过15行。

为什么定这个数呢?

一方面，这个是基于多年开发实践的总结。

15行其实已经是一个比较宽松的标准，开发人员稍加培训就可以实际贯彻，而符合这个标准的函数也能达到良好的可读性。

2

另一方面，这是基于对函数复杂度和代码行数之间关联关系的认识。

我采用一个简单的数学公式：

方法复杂度 >= 代码行数^2

以下为了简化，只以最低增长方式，平方数进行计算。

以一个函数的行数，从1行到20行为例，见下图：

当函数行数到达10行以上，函数复杂度就开始大幅度攀升。

当代码行数达到20行时(复杂度400)，其复杂度已经是14行时(复杂度 196)的2倍。

因此我将代码规范定在15行。

下面我们运行此公式，来分析一下提炼小函数的好处。

例如，有1个100行的函数，分解为11(含自身)个10行的函数。

原复杂度= 100^2=10000。

分解后复杂度= 11×(10^2)= 1100。

分解后的复杂几乎是分解前的 1/9，几乎降低了1个数量级。

这就解释了为什么长方法分解之后，可维护性大幅度提高。

也就无怪乎有同学表示维护1000行以上的函数，有种生不如死的感受。

免责声明：本文由java培训机构的小编转载自网络，旨在分享阅读，版权归原作者所有，如有侵权请联系我们进行删除，更多java精彩内容请关注Java培训官网