可能重复：
什么时候函数太长？
我最近接到了一项令人羡慕的任务，即审查另一位开发人员编写的糟糕代码并记录不良做法。（当然，这一切都是为了摆脱为开发人员的工作付出的代价，而不是任何利他的理由！）
审查过的代码有几个程序是多行代码 - 最长的将近 600 行。我想到的几个问题是可维护性和可读性。
诀窍是我需要向外行证明为什么这是一种不好的做法，并且如果可能的话，用一本备受推崇的最新参考书来支持它。类比也很好。
有任何想法吗？
重复： 什么时候函数太长？
重复： 最大函数大小的最佳规则？
Alex Angas
问问题
51545 次
6 回答
142
这与代码行无关。正如史蒂夫·麦康奈尔和鲍勃·马丁所说（关于编码最佳实践的两个很好的参考资料），一种方法应该做一件事，而且只做一件事。然而，做这件事需要多少行代码，它应该有多少行。如果那个“一件事”可以分解成更小的东西，那么每一个都应该有一个方法。
很好的线索你的方法做的不止一件事：
- 一个方法中的多个缩进级别（表示太多的逻辑分支只做一件事）
- “段落中断” - 逻辑代码组之间的空白表示该方法正在做不止一件事
仅举几个。Bob Martin 还说要保持在 10 左右。就我个人而言，我通常会尝试为 10 投篮。如果它开始接近 20，那就是一个精神信号，需要更加关注这种方法。但归根结底，代码行数对于几乎任何事情都是一个糟糕的衡量标准。它只是一个有用的指标，可以潜在地指向真正的问题。
于 2009-03-04T16:23:36.363 回答
14
真正的答案
没有具体数字。
一个具体的答案
如果您必须向律师或其他人证明一些数字的合理性，请找出适合您商店的典型开发编辑器窗口的最大行数，然后使用它。
一般实践
你甚至不应该那样看待它，但任何一个函数都应该没有什么非常复杂的事情发生。
每个工作单元都应该委托给它自己的单元测试的描述性命名方法。 这样做，您的所有方法最终都会变得很小且可读，而无需计算行数......
我看到的最大违规者是在 if 语句中间爆炸的 3-4+ 布尔条件。用一个好名字将所有这些包裹在一个布尔值中，然后将任何组成它的部分包裹起来，这些部分本身就很复杂。
于 2009-03-04T16:30:45.817 回答
8
首先，请注意长度限制与通常的度量标准是完全分开的，即“函数是否只做一件事，并且做得很好？” 如果该问题的答案不是肯定的，那么无论长度如何，该功能都可能不是一个好的功能。
与最大长度特别相关，来自 Code Complete 的引用，通常被认为是关于编码实践主题的最佳书籍之一：
有时，复杂的算法会导致更长的例程，在这种情况下，应该允许例程有机地增长到 100-200 行。（一行是源代码的非注释、非空白行。）数十年的证据表明，这种长度的例程并不比较短的例程更容易出错。让嵌套深度、变量数量和其他与复杂性相关的考虑因素决定例程的长度，而不是强加长度限制本身。
如果您想编写超过 200 行的例程，请小心。没有一项研究报告降低了成本、降低了错误率，或者两者兼而有之，较大的例程可以区分大小超过 200 行的代码，并且当您传递 200 行代码时，您必然会遇到可理解性的上限。
于 2009-03-04T16:31:25.877 回答
5
尽可能少。
于 2009-03-04T16:25:39.697 回答
2
为了补充 Rex 的观点，它也应该尽可能短。鲍勃·马丁说 10 或更少
于 2009-03-04T16:24:11.900 回答
2
自从我读到这篇文章已经很多年了，但我认为在学习 Perl中，他们建议制作一个程序，而不是你可以一次在屏幕上显示整个内容。我认为这是一个很好的衡量标准。我见过由于重复代码（例如数据库访问和分配属性值）而仍然可读的较长函数，但这些是例外而不是常态。
于 2009-03-04T16:25:43.707 回答