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

Question

  

可能重复：
  When is a function too long?

我最近被赋予了一项不值得羡慕的任务，即审查其他开发人员编写的糟糕代码并记录不良做法。 （当然，这只是出于为开发人员的工作付出代价而不是任何无私的理由！）

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

诀窍在于我需要向外行人证明为什么这是一种不好的做法，并且如果可能的话，用备受好评和当前的参考书来支持它。类比也很好。

有什么想法吗？

重复： When is a function too long?
重复： Best rule for maximum function size?

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

要添加到雷克斯的观点，它也应该尽可能短。鲍勃马丁说10或更少

Object Mentor - How big should a function be?

Answer 5

自从我读到这篇文章以来已经很多年了，但我认为它是在 Learning Perl 中，他们建议制作一个程序不要超过你可以立即将整个事情放在屏幕上。我认为这是一个很好的尺度。我已经看到由于重复代码（例如数据库访问和分配属性值）而仍然可读的较长函数，但这些是异常而不是常态。

Answer 6

尽可能少。