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

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 所说（关于编码最佳实践的两个很好的参考资料），一个方法应该做一件事，而且只做一件事。然而，做这件事需要多少行代码是它应该有多少行。如果那个“一件事”可以分解成更小的事物，那么每个事物都应该有一个方法。

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

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

仅举几例。 Bob Martin 还说要保持在 10 左右。就我个人而言，我通常会尝试投 10 分。如果它开始接近 20 分，那就是要密切注意这种方法的精神标志。但归根结底，代码行数对于几乎任何事情都是一个糟糕的衡量标准。它只是一个有用的指标，可以潜在地指出真正的问题。

Answer 2

真正的答案

没有具体数字。

一个具体的答案

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

一般实践

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

每个工作单元都应该委派给它自己的可单元测试的描述性命名方法。 这样做，你的所有方法最终都会变得很小且可读，而无需计算行数......

我看到的最大问题是在 if 语句中间爆炸了 3-4+ 个布尔条件。用一个好名字将所有这些都封装在一个布尔值中，然后将任何组成它的部分都封装起来。

Answer 3

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

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

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

如果您要编写超过 200 行的例程，请小心。没有一项研究报告降低了成本、降低了错误率，或者两者兼而有之，较大的例程可以区分大小超过 200 行的代码，并且当您传递 200 行代码时，您必然会遇到可理解性的上限。

Answer 4

尽可能少。

Answer 5

自从我读到这篇文章已经很多年了，但我认为在 Learning Perl 中，他们建议制作的程序不要超过您一次可以将整个内容显示在屏幕上的时间。我认为这是一个很好的衡量标准。我见过由于重复代码（例如数据库访问和分配属性值）而仍然可读的较长函数，但这些是例外而不是常态。

Answer 6

为了补充 Rex 的观点，它也应该尽可能短。 Bob Martin 说 10 或更少

Object Mentor - How big should a function be?