方法重构

Question

在您需要更好地设计之前，方法可以使用多少行代码进行良好的设计？

Answer 1

Lines of code is an incomplete metric to use for refactoring. Cyclomatic Complexity should be used in conjuction with LOC as a decent gauge for when to refactor.

A decent guideline is

LOC > 80 || CC > 10 == "Time to refactor"

Chances are you will hit a Cyclomatic Complexity > 10 long before you ever reach 80 lines of code.

Of course there are a litany of other metrics to consider as well:

1. Afferent Coupling: How many methods depend on this method
2. Efferent Coupling: How many methods does this method rely on
3. No. of Parameters
4. No. of Varialbes used

You can go pretty in depth, but all this to say that determining when to refactor can't be decided with a blanket rule like "Thou shalt not have more than 40 lines in any method!"

Answer 2

There is no accepted rule. It should be as simple to read as possible. If that means taking 5 lines of a 10 line block and putting them in their own method, then so be it. But sometimes it can be fine to have 50-line methods. Just do what you think you'll understand best in 6 months time.

Answer 3

Depends on what the method does. There's a fine line between writing too few methods and too many methods, and much of it is a matter of personal taste.

My opinion:

• 50 lines is too long for a method. I think methods shorter than this are often too long as well, but that's my highest threshold for method length.
• Methods should be written so that they're used more than once. Don't refactor just to make an existing method shorter; refactor to make reusable methods that other methods will benefit from.

There are no arbitrary limits on the length of code a method can have before it needs to be redesigned. However, usually if a method feels "too long", it's a sign that you're doing something wrong.

Answer 4

Not as a rule, but as a heuristic, when a method goes over 25 lines I give it a once over to see if I can break it into simpler components.

This is not to say that methods over 25 lines are never well designed, or that shorter methods are always better than longer ones. It's just a good heuristic to follow.

Answer 5

As many as it takes to logically and clearly perform the one single task that method performs.

Seriously, there is no yardstick. Generally people like to be able to see an entire method within one page on their monitor, so that's one thing to consider. But line count is not your primary indicator of logic problems. Too many developers have obfuscated code and made future support more difficult by trying to get it into as few lines as possible.

There's nothing inherently wrong with 1,000 lines of code in a single method, if that's what it takes to logically and clearly perform that task. It's rare, and a method that long is usually a sign to re-factor, but it's possible. There is something inherently wrong with 1,000 lines of spaghetti code all doing different things and interacting in strange ways in a single method. The line count isn't the problem.

Answer 6

Probably, we should consider "Responsibility" implemented by a method here rather than go by hard numbers. If we try to limit a method to a single responsibility, LOC will be taken care automatically.

Another rule of thumb that we can follow is to limit the length of a method that we can see on a single screen.

Answer 7

Lines of code is one metric, but another to look at is code paths. Each if, and, or, loop, etc. makes the function more complex. You can have very short, complex functions and it's possible to have simple to understand, but long, functions. Refactoring works well when you use it reduce complexity, not necessarily lines of code.

For example:

if (color.r == color.g && color.r == color.b)
    if (color.r > 128)
       newColor = color.White;
    else
       newColor = color.Black;

vs

if(isGray(color))
   newColor = thresholdGray(color)

The intent is clearer, and the number of paths is reduced.

Answer 8

It's true that LOC is a lousy metric, because it doesn't correlate well with the property you are really interested in (quality of design). But its great strength as a metric - and the reason it is so widely used and discussed - is of course how easy it is to measure. That's not pure laziness; for a fraction of one percent of the effort, you get - well, maybe 20 or 30 percent of the value of more meaningful metrics. You can just glance at a method, or the last line of a class, and assess the LOC metric. You can just look at the height of the scroll bar and have a pretty good idea.

And there are real LOC limits that make sense - too many to fit on a monitor, or on a page of text, is really too many, notwithstanding the simplicity and cohesiveness.

I like really short methods. One-liners are great. When a method starts to head into double digit LOC, it itches. If it's 30 or more, it's painful. Go ahead and use LOC; just understand its weakness as a metric, and know what better metrics (eg cyclomatic complexity) exist. Use them when you need something better.