函数/过程/方法应该有多少行代码？

Question

可能重复:
函数何时太长？

我最近得到了一个不值得羡慕的任务,即审查另一个开发人员编写的糟糕代码并记录不良做法.(当然,这都是出于为开发人员的工作付出代价而不是任何无私的理由!)

经过审核的代码有几行代码,其中包含多行代码 - 最长的代码是600行.我想到的几个问题是可维护性和可读性.

诀窍在于我需要为一个外行人辩护,为什么这是一个不好的做法,如果可能的话,用一本备受好评的当前参考书备份它.类比也很好.

有任何想法吗？

重复: 函数何时太长？
重复: 最大功能大小的最佳规则？

Answer 1

这不是关于代码行.正如Steve Mcconnell和Bob Martin所说(关于编码最佳实践的两个非常好的参考资料),一种方法应该只做一件事而且只做一件事.然而,做一件事需要多行代码就是它应该有多少行.如果"一件事"可以分解成更小的东西,那么每个东西都应该有一个方法.

好的线索你的方法做了不止一件事:

• 方法中多个级别的缩进(表示太多逻辑分支​​只能做一件事)
• "Paragraph Breaks" - 逻辑代码组之间的空格表示该方法不止一件事

仅举几个.鲍勃马丁也说保持在10左右.就我个人而言,我通常会尝试射击10.如果它开始接近20,这是一个精神上的旗帜,要密切关注这种方法.但最终,LoC对于几乎任何事情来说都是一个糟糕的指标.它只是一个有用的指标,可能潜在地指出真正的问题.

Answer 2

真正的答案

没有具体的数字.

一个具体的答案

如果您必须向律师或其他人证明某些数字,请找出适合您商店典型开发编辑窗口的最大行数,并使用它.

全科医学

你甚至不应该这样看待它,但任何一个函数都不应该有任何复杂的事情发生.

应将每个工作单元委托给自己的单元可测试的描述性命名方法. 做到这一点,你所有的方法都是微小的,可读的,没有计算线......

我看到的最大的攻击者是在if语句中间爆炸的3-4 +布尔条件.用一个好名字将所有内容包装在一个布尔值中,然后将构成它们的任何部分包装起来都是复杂的.

Answer 3

首先,请注意长度限制完全独立于通常的度量标准,即"函数只做一件事,做得好吗？" 如果该问题的答案不是肯定的,那么无论如何,该功能可能都不是好的,无论长度如何.

与最大长度相关,来自Code Complete的引用,通常被认为是关于编码实践主题的最佳书籍之一:

有时,复杂的算法会导致更长的例行程序,在这种情况下,应该允许例程有机地增长到100-200行.(一行是一个非注释,非空白的源代码行.)数十年的证据表明,这种长度的例程不会比较短的例程更容易出错.让嵌套深度,变量数量和其他与复杂性相关的考虑因素等问题决定了例程的长度,而不是强加长度限制本身.

如果要编写超过约200行的例程,请小心.没有一项报告显示降低成本,降低错误率,或两者都有较大的例程,区分大于200行,并且当你传递200行代码时,你必然会遇到可理解性的上限.

Answer 4

尽可能少。