可能重复：
一个函数/过程/方法应该有多少行代码？
我想知道函数应该有多少行代码？多少行太多了。
我不久前读过这篇文章，大约有 10 或 20 行，但这是因为屏幕只能容纳这么多行。现在随着屏幕尺寸变大，这将不成立。
让我们假设函数的任何部分都没有在其他任何地方使用，即忽略 DRY 原则。
我想听听其他人对此有何看法。
谢谢。
注意：函数何时重复太长？, 发帖的时候找不到。
问问题
1924 次
10 回答
17
线条无关紧要，但复杂性才是。
一个函数应该完成一项任务，并且应该很明显。您只需花几分钟就可以准确了解该功能的作用方式和作用。
于 2010-06-04T18:45:33.393 回答
6
这类问题在Code Complete中得到了很好的回答。Steve McConnel 写了一整页来回答这个问题。他的结论：
数十年的证据表明，如此长度（>100 行）的例程并不比较短的例程更容易出错。让例程的凝聚力、决策点的数量、解释例程所需的注释数量以及其他与复杂性相关的考虑因素决定例程的长度，而不是对其本身施加长度限制。也就是说，如果您想编写超过 200 行的例程，请小心。
于 2010-06-04T18:57:12.950 回答
4
它应该有尽可能多的。
我认为将函数行数限制为屏幕大小没有任何意义（公平地说，我直到屏幕可以容纳超过 10-20 行之后才开始编程 - 也许这在某些环境中确实有意义） . 只需编写有意义的函数即可。当它变得如此之大以至于代码片段开始重复时，将这些片段重构为其他函数/类/组件。
于 2010-06-04T18:43:16.750 回答
2
这是一个相当随意的经验法则。有些喜欢 20 行，有些喜欢不滚动规则。最后，只要确保它可读且易于理解即可。阅读您的 SOLID 原则并确保该方法只有一项责任，等等。
于 2010-06-04T18:43:35.037 回答
1
只要必要，尽可能短。
我将 5-10 行作为经验法则，但如果有一些逻辑不能（重新）容易地分解为多个函数，我会在必要时写更长的时间。另一方面，我经常有只有一两行长的函数。
如果您没有立即理解代码的一部分是做什么的，请为它编写一个新函数。
于 2010-06-04T18:47:46.500 回答
0
我认为它有多少行并不重要……只要它是有效的。
任何可以在代码库中任何地方重用的代码都应该移动到同一类或共享类中的另一个函数/方法并调用。
于 2010-06-04T18:43:56.190 回答
0
我以前也听说过屏幕尺寸指标，但显然不是硬限制或随显示器尺寸缩放。它只是为了传达 DRY 的原则，并且保持函数尽可能小是编写可扩展代码的最佳方法之一（在项目大小中）。
于 2010-06-04T18:44:43.367 回答
0
Linux Kernel Coding Style 文档说：
函数应该短小精悍，只做一件事。它们应该适合一两屏文本（众所周知，ISO/ANSI 屏幕尺寸为 80x24），并且做一件事并做好。
现在，我意识到这是在内核代码的上下文中，但我认为它提出的一些观点：函数长度通常是有效的。在此处查找副本。函数部分是第 4 章。
总而言之，函数长度不应该受到一些人为规则的限制；如果有意义就将内容排除在外，因为它使内容更易于阅读，但是关于 1-2 个屏幕的规则并不是一成不变的。
于 2010-06-04T18:49:23.243 回答
0
这只是从 oo 角度的观点：
我更喜欢将我的方法保留在逻辑工作单元中，并且并不真正关心诸如 LoC 之类的指标。这使得正确命名您的方法也很容易，并防止它们变得臃肿。
一个非常简单的函数示例将不是在循环中内联计算斐波那契序列的函数，而是添加一个由 fibonacci() 函数调用的后继（int a，int b）函数。
OO 方式中更复杂的示例是执行 GET 请求的 http 客户端。我会把它分解成这样的：
Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)
于 2010-06-04T19:02:11.410 回答
0
函数应该足够小以完成它们的工作，但不能更小。
于 2010-06-04T19:23:19.710 回答