可能重复：
How many lines of code should a function/procedure/method have?
我想知道函数应该有多少行代码？多少行太多了。
我不久前读过这篇文章，大约有 10 或 20 行，但这是因为屏幕只能容纳这么多行。现在随着屏幕尺寸变大，这将不成立。
让我们假设函数的任何部分都没有在其他任何地方使用，即忽略 DRY 原则。
我想听听其他人对此有何看法。
谢谢。
注意：When is a function too long?的重复，我发帖时找不到。
【问题讨论】：
线条无关紧要，但复杂性才是。
一个函数应该完成一项任务，并且应该很明显。您只需片刻即可准确了解该函数的作用方式和作用。
【讨论】：
此类问题在Code Complete 中得到了很好的解答。 Steve McConnel 写了一整页来回答这个问题。他的结论：
数十年的证据表明，例行公事 这样的长度（> 100 行）是没有 比更短更容易出错 例行公事。 让诸如 套路的凝聚力，决策的数量 点数，需要的 cmets 数 解释例程和其他 复杂性相关的考虑 规定例程的长度 而不是强加一个长度 限制本身。也就是说，如果你 想写例程比 大约200行，小心。
【讨论】：
它应该有尽可能多的。
我认为将函数行数限制为屏幕大小没有任何意义（公平地说，我直到屏幕可以容纳超过 10-20 行之后才开始编程 - 也许这在一些环境）。只需编写有意义的函数即可。当它变得如此之大以至于代码片段开始重复时，将这些片段重构为其他函数/类/组件。
【讨论】：
这是一个相当随意的经验法则。有些喜欢 20 行，有些喜欢不滚动规则。最后，只要确保它可读且易于理解即可。阅读您的 SOLID principles 并确保该方法只有 1 个职责，等等。
【讨论】：
尽可能长，尽可能短。
我将 5-10 行作为经验法则，但如果有一些逻辑不能（重新）轻松分解为多个函数，我会在必要时写更长的时间。另一方面，我经常有只有一两行长的函数。
如果您不立即理解代码的一部分是做什么的，请为它编写一个新函数。
【讨论】：
我认为它有多少行并不重要......只要它是有效的。
任何可以在代码库中任何地方重用的代码都应该移动到同一类或共享类中的另一个函数/方法并调用。
【讨论】：
我以前也听说过屏幕尺寸指标，但显然不是硬限制或随显示器尺寸缩放。它只是为了传达 DRY 的原则，并且保持函数尽可能小是编写可扩展的代码的最佳方法之一（在项目大小中）。
【讨论】：
Linux 内核编码风格文档说：
函数应该简短而甜美， 只做一件事。他们应该 适合一两屏文本 （ISO/ANSI 屏幕尺寸为 80x24，如 我们都知道），做一件事，做 很好。
现在，我意识到这是在内核代码的上下文中，但我认为它提出的一些观点：函数长度通常是有效的。查找副本here。函数部分是第 4 章。
总而言之，函数长度不应该受到一些人为规则的限制；如果有意义就将内容排除在外，因为它使内容更易于阅读，但是关于 1-2 个屏幕的规则并不是一成不变的。
【讨论】：
这只是一个OO视角的观点：
我更喜欢将我的方法保留在逻辑工作单元中，而不真正关心诸如 LoC 之类的指标。这也使得正确命名您的方法变得非常容易，并防止它们变得臃肿。
一个非常微不足道的函数示例不是在循环中内联计算斐波那契数列的函数，而是添加一个由 fibonacci() 函数调用的 successor(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)
【讨论】：
函数应该足够小以完成它们的工作，但不能更小。
【讨论】：