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

Question

可能的重复：
函数什么时候太长？

最近，我接到了一项令人羡慕的任务：审查另一位开发人员编写的不良代码并记录不良做法。（当然，这都是为了摆脱开发人员的工作报酬，而不是出于任何利他的原因！）

审查的代码有几个程序，代码很多行——最长的几乎有600行。我想到的几个问题是可维护性和可读性。

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

有任何想法吗？

复制： 函数什么时候太长？
复制： 最大函数大小的最佳规则？

Answer 1

这与代码行无关。作为 史蒂夫·麦康奈尔 和 鲍勃·马丁 比如说（关于编码最佳实践的两篇非常好的参考文献），一个方法应该做一件事并且只做一件事。不管需要多少行代码来完成这一件事，重要的是它应该有多少行。如果“一件事”可以分解成更小的事情，那么每一个事情都应该有一个方法。

很好的线索，你的方法不仅仅做一件事：

• 方法中的缩进超过一级（表示逻辑分支过多而无法只做一件事）
• “段落分隔符” - 逻辑代码组之间的空格表示该方法正在执行不止一件事

仅举几个。鲍勃·马丁 (Bob Martin) 还表示将其保持在 10 左右。就我个人而言，我通常会尝试拍摄 10 个。如果它开始接近 20，则表明需要更加关注该方法。但归根结底，LoC 对于几乎任何事情来说都是一个糟糕的指标。它只是一个有用的指标，有可能指出真正的问题。

Answer 2

真正的答案

没有具体的数字。

具体答案

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

全科医学

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

每个工作单元都应该委托给自己的单元可测试的描述性命名方法。 这样做，你所有的方法都会变得微小而且可读，而不用计算线......

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

Answer 3

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

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

  

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

     

如果要编写长度超过200行的例程，请小心。所有报告的研究都没有降低成本，降低错误率，或者两者都有较大的例程，区分大于200行的大小，并且当你传递200行代码时，你必然会遇到可理解性的上限。 / p>

Answer 4

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

Answer 5

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

对象导师 - 一个函数应该有多大？

Answer 6

尽可能少。