How many lines of code should a function/procedure/method have? [duplicate]

问题

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?
Duplicate: Best rule for maximum function size?

回答1:

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:

More than one level of indention in a method (indicates too many logic branches to only be doing one thing)
"Paragraph Breaks" - whitespace between logical groups of code indicate the 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, LoC is a bad metric for pretty much anything. It is only a helpful indicator that can potentially point to the real issue.

回答2:

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.

回答3:

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:

From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as depth of nesting, number of variables, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se.

If you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code.

回答4:

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.