函数长度应该有多大（函数中的代码行）？
可能的重复：
函数/过程应该有多少行代码/方法有吗？
我想知道function应该有多少行代码？多少行太多了。
我不久前读过这篇文章，大约有 10 或 20 行，但这是因为屏幕只能容纳这么多行。现在，随着屏幕尺寸变得更大，这种情况不再适用。
假设函数的任何部分都没有在其他地方使用，即忽略 DRY 原则。
我想听听其他人对此有何看法。
谢谢。
注意：重复函数何时太长？，我发帖的时候没找到。
Possible Duplicate:
How many lines of code should a function/procedure/method have?
I would like to know how many lines of code should be function have? How many lines is too much.
I read this a while back, it around 10 or 20 lines but it was because the screen would only accommodate so many lines. Now as the screen size become larger, that would not hold true.
Let's assume that the no part of the function is used anywhere else i.e. disregard DRY principle.
I'd like to hear what others have to say about this.
thanks.
Note: Duplicate of When is a function too long?, could not find it when I posted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
线条无关紧要，但复杂性却重要。
一个函数应该完成一项任务，并且它应该是显而易见的。您不需要花太多时间就能准确理解该函数的功能和用途。
Lines are irrelevant, but complexity is.
A function should do one task, and it should be readily apparent. It shouldn't take you more than a few moments to understand exactly how and what the function does.
此类问题在Code Complete 中得到了很好的解答。 Steve McConnel 写了一整页来回答这个问题。他的结论是：
This kind of question is well answered in Code Complete. Steve McConnel wrote an entire page to answer this question. His conclusion:
它应该有它需要的数量。
我不认为将函数行数限制为屏幕大小有任何意义（公平地说，直到屏幕可以容纳超过 10-20 行之后我才开始编程 - 也许这在某些环境中确实有意义） 。只需编写有意义的函数即可。当它变得如此之大以至于代码片段开始重复时，请将这些片段重构为其他函数/类/组件。
It should have as many as it needs.
I don't see any point in restricting a function line-count to screen size (ok to be fair, I didn't start programming until after screens could accomadate more than 10-20 lines - maybe this did make sense in some environments). Just write the function as it makes sense to. When it gets so large that pieces of code start repeating, refactor those pieces to other functions/classes/components.
这是一个相当任意的经验法则。有些人喜欢 20 行，有些人喜欢无滚动规则。最后，只要确保它可读并且一目了然即可理解。仔细阅读您的SOLIDprinciples并确保该方法只有 1 个职责， ETC。
It's a pretty arbitrary rule of thumb. Some like 20 lines, others like the no-scroll rule. In the end, just make sure it's readable and easily understood at a glance. Read over your SOLID principles and make sure the method has only 1 responsibility, etc.
只要需要，就尽可能长，尽可能短。
我将 5-10 行作为经验法则，但如果有一些逻辑无法轻松（重新）分解为多个函数，我会在必要时编写更长的代码。另一方面，我经常拥有只有一两行长的函数。
如果您不能立即理解部分代码的作用，请为其编写一个新函数。
As long as necessary, as short as possible.
I take 5-10 Lines as a rule of thumb but if there is some logic that can't be (re)factored easily into multiple functions i write longer where necessary. On the other hand i often have functions that are just a line or two long.
If you do not immedatly understand what a part of code does, write a new function for it.
我以前也听说过屏幕尺寸指标，但显然无意成为硬性限制或随显示器尺寸缩放。它只是为了传达 DRY 原则，并且保持函数尽可能小是编写可扩展代码（按项目大小）的最佳方法之一。
I've heard the screen size metric before too but obviously not intended to be a hard limit or to scale with monitor size. It's just intended to convey the principle of DRY and that keeping functions as small as possible is one of the best ways to write code that can scale (in project size).
Linux 内核编码风格文档说：
现在，我意识到这是在内核代码的上下文中，但我认为它提出的一些观点：函数长度通常是有效的。在此处查找副本。关于函数的部分是第4章。
总而言之，函数长度不应该受到某些人为规则的限制；如果有意义，并且因为它使内容更容易阅读，则将其排除在外，但关于 1-2 个屏幕的规则并不是一成不变的。
The Linux Kernel Coding Style document says:
Now, I realize this is in the context of kernel code, but I think some of the points it makes re: function length are generally valid. Find a copy here. The section on functions is Chapter 4.
All in all, function length shouldn't be constrained by some artificial rule; factor stuff out if it makes sense, and because it makes stuff easier to read, but the rule about 1-2 screens is not written in stone.
这只是从面向对象的角度提出的意见：
我更喜欢将我的方法保留在工作的逻辑单元中，并且并不真正关心像 LoC 这样的指标。这使得正确命名你的方法也变得非常容易，并防止它们变得臃肿。
一个非常简单的函数示例是，我不会添加一个在循环中内联计算斐波那契序列的函数，而是添加一个由 fibonacci() 函数调用的 successor(int a,int b) 函数。
OO 风格中更复杂的示例是执行 GET 请求的 http 客户端。我会把它分解成这样的：
this is just an opinion from an oo-perspective:
i prefer to keep my methods in logical units of work and dont really care about metrics like LoC. this makes it also quite easy to properly name your methods, and keeps them from getting bloated.
a very trivial functional example would be instead of having a function that calculates the fibonacci sequence inline in a loop i would add a successor(int a,int b) function, that gets called by the fibonacci() function.
a more complex example in oo fashion would be a http client that performs a GET request. i'd break that up into something like this:
函数应该足够小以完成其工作，但不能更小。
Functions should be exactly small enough to do their job, but no smaller.
我认为它有多少条线并不重要……只要它高效即可。
任何可以在代码库中的任何位置重用的代码都应该移动到同一类或共享类中的另一个函数/方法并进行调用。
I don't think it matters how many lines it has...as long as it's efficient.
Any code that can be reused anywhere in your codebase should be moved to another function/method in the same class or a shared class and called.