子程序可以写多长

在前往美洲的途中，英国清教徒们（Pilgrims）就日常工作（routine）的最大长度限度展开了争论。他们争执了一路，最终到达了普利茅斯巨礁（Plymouth Rock），然后便开始起草五月花协议（Mayflower Compact）。这时，他们仍然无法就最大长度问题达成一致，而如果他们不签订五月花协议就不能登陆，因此他们放弃了争论而把这项内容排除在协议之外。而由此带来的结果就是，从此以后人们就“routine”的长度问题展开了旷日持久的讨论。

理论上认为的子程序最佳最大长度通常是一屏或一到两页列印代码，也就是约50~150行代码。按这种精神，IBM曾经把子程序的长度限制在50行之内，而TRW则把这一长度限制在两页纸之内（McCabe 1976）。现代的计算机程序通常都是由很多极短的子程序外加少量较长的子程序组成。然而很长的子程序却也仍然存在。在即将完成本书的时候，我曾在一个月的时间里登门拜访了两家客户。其中一家的程序员们正在与一段4000多行代码的子程序较劲，而另一家的程序员们则在试图弄懂一段超过12000行代码的子程序！

多年来，人们已经在子程序的长度问题上积累了大量的研究成果，其中一些适用于现代编程，而另一些则不尽如此：

■           Basili和Perricone所做的一项研究发现，子程序的长度与错误量成反比，即：随着子程序长度的增加（上至200行代码），每行代码所包含的错误数量就会减少（Basili和Perricone 1984）。

■           另一项研究则发现，子程序的长度与错误量没有关联，而结构复杂度以及数据量却与错误量有关（Shen et al. 1985）。

■           1986年所做的一项研究发现，短小的子程序（含有32行或更少代码）与更低的成本或错误率无关（Card，Church and Agresti 1986；Card and Glass 1990）。有证据表明，较长的子程序（含有65行或更多代码）使得每行代码的成本更低。

■           一项对450个子程序所做的实证研究发现，相对较长的子程序而言，短小的子程序（包括注释在内少于143行语句）中每行代码所含的错误数量要多23%，而修改成本却低2.4倍（Selby and Basili 1991）。

■           另一项研究发现，平均长度为100到150行代码的子程序需要被修改的几率最低（Lind and Vairavan 1989）。

■           IBM所做的一项研究发现，最容易出错的是那些超过500行代码的子程序。超过500行之后，子程序的出错率就会与其长度成正比（Jones 1986a）。

那么，上述这些研究对于面向对象程序中子程序的长度又意味着什么呢？在面向对象的程序中，一大部分子程序都是访问器子程序（accessor routines），它们都非常短小。在任何时候，复杂的算法总会导致更长的子程序。在这种情况下，可以允许子程序的长度有序地增长到100至200行（不算源代码中的注释行和空行）。数十年的证据表明，这么长的子程序也和短小的子程序一样不易出错。与其对子程序的长度强加限制，还不如让下面这些因素——如子程序的内聚性、嵌套的层次、变量的数量、决策点（decision points）的数量、解释子程序用意所需的注释数量以及其他一些跟复杂度相关的考虑事项等——来决定子程度的长度。

这就是说，如果要编写一段超过200行代码的子程序，那你就要小心了。对于超过200行代码的子程序来说，没有哪项研究发现它能降低成本和/或降低出错率，而且在超过200行后，你迟早会在可读性方面遇到问题。