可能的重复：
什么时候函数太长？
我最近接到了一项令人羡慕的任务审查其他开发人员编写的不良代码并记录不良实践。 （当然，这都是为了摆脱开发人员的工作报酬，而不是出于任何利他的原因！）
经过审查的代码有几个程序，有很多行代码 - 最长的几乎有 600 行。 我想到的几个问题是可维护性和可读性。
诀窍在于，我需要向外行证明为什么这是一种不好的做法，并且如果可能的话，用一本备受推崇的最新参考书来支持它。 类比也很好。
有任何想法吗？
重复： 函数何时太长？
Possible Duplicate:
When is a function too long?
I've recently been given the unenviable task of reviewing poor code written by another developer and documenting the bad practices. (This is all for the purposes of getting out of paying for the developer's work rather than any altruistic reason, of course!)
The reviewed code has several procedures that are many lines of code - the longest is almost 600 lines. A couple of problems with this that I've thought of are maintainability and readability.
The trick is that I need to justify to a layperson why this is a bad practice and if possible back it up with a well regarded and current reference book. Analogies are good too.
Any ideas?
Duplicate: When is a function too long?
发布评论
评论（6）
这与代码行无关。 正如 Steve McConnell 和 Bob Martin 说（关于编码最佳实践的两篇非常好的参考文献），一个方法应该做一件事，而且只能做一件事。 不管需要多少行代码来完成这一件事，重要的是它应该有多少行。 如果“一件事”可以分解成更小的事情，那么每个事情都应该有一个方法。
好的线索表明您的方法正在执行不止一件事：
仅举几例。 Bob Martin 还说将其保持在 10 左右。就我个人而言，我通常会尝试争取 10。如果它开始接近 20，则表明需要更加关注该方法。 但归根结底，代码行数对于几乎任何事情来说都是一个不好的衡量标准。 它只是一个有用的指标，有可能指出真正的问题。
It's not about lines of code. As Steve Mcconnell and Bob Martin say (two pretty good references on coding best practices), a method should do one thing and only one thing. However many lines of code it takes to do that one thing is how many lines it should have. If that "one thing" can be broken into smaller things, each of those should have a method.
Good clues your method is doing more than one thing:
Just to name a few. Bob Martin also says to keep it around 10. Personally I usually try to shoot for 10. If it starts getting close to 20, that's a mental flag to pay closer attention to that method. But ultimately, lines of code are a bad metric for pretty much anything. It is only a helpful indicator that can potentially point to the real issue.
真正的答案
没有具体的数字。
具体答案
如果您必须向律师或其他人证明某个数字的合理性，请计算出适合您商店中典型开发编辑器窗口的最大行数，然后使用它。
一般实践
您甚至不应该真正这样看待它，但任何一个函数中都不应该发生任何非常复杂的事情。
每个工作单元都应该委托给其自己的单元可测试的描述性命名方法。 这样做，你所有的方法都会变得很小并且可读，而无需计算行数......
我看到的最大的问题是 3-4+ 布尔条件在 if 语句中间爆炸。 将所有这些内容包装在一个具有好名称的布尔值中，然后将组成它的任何本身复杂的部分包装起来。
The Real Answer
There's no specific number.
A Concrete Answer
If you have to justify with some number to lawyers or something, figure out the maximum number of lines that fit on a typical development editor window at your shop, and use that.
General Practice
You shouldn't even really look at it that way, but there should be nothing very complex going on in any one function.
Each unit of work should be delegated to its own unit testable descriptively named method. Do this and all your methods end up tiny and readable without ever counting lines......
The biggest offender I see is 3-4+ boolean conditions exploded in the middle of an if-statement. Wrap all that up in one boolean with a good name, then wrap up any pieces that make it up that are complex in their own.
首先，请注意，长度限制与通常的度量完全分开，通常的度量是“函数是否只做一件事，并且做得很好？” 如果这个问题的答案是否定的，那么无论长度如何，该函数都可能不是一个好的函数。
特别与最大长度相关的是《Code Complete》中的一段话，该书通常被认为是关于编码实践主题的最佳书籍之一：
First of all, note that the length restriction is entirely separate from the usual metric, which is "does the function do only one thing, and do it well?" If the answer to that question isn't yes, the function is probably not a good one anyway, regardless of length.
Relevant specifically to the maximum length, a quote from Code Complete, generally considered to be one of the best books on the subject of coding practices:
尽可能少。
As few as possible.
为了补充雷克斯的观点，它也应该尽可能短。 鲍勃·马丁说 10 个或更少
对象导师 - 函数应该有多大？
To add to Rex's point, it should also be as short as possible. Bob Martin says 10 or fewer
Object Mentor - How big should a function be?
我已经很多年没有读过这篇文章了，但我认为在学习 Perl 中，他们建议制作一个过程的长度不要超过你可以一次在屏幕上显示整个内容的长度。 我认为这是一个很好的衡量标准。 我见过较长的函数由于重复的代码（例如数据库访问和分配属性值）而仍然可读，但这些都是例外而不是常态。
It's been many years since I read this, but I think it was in Learning Perl that they recommend making a procedure no longer than you can fit the whole thing on the screen at once. I thought this was a good yardstick. I've seen longer functions that were still readable because of repetitive code (e.g. database access and assigning property values), but those are the exception rather than the norm.