3

As far as I've learnt already, a method containing a long sequence of operations is considered a bad thing and needs to be redesigned. More than that, I heard an opinion that the method should not be bigger than the screen (i.e. all method code should be visible in IDE screen at once, without need of scrolling).

Are there any general rules about this? For example, "if method is more than 15 lines long, it should be refactored"? And if so, how do you refactor it? Just use the extract method way?

SPIRiT_1984
  • 2,717
  • 3
  • 29
  • 46

3 Answers3

6

It depends on who you ask. Robert Martin will tell you that there are two rules:

  1. A method should be small.
  2. A method should be smaller than that.

Don't think of it in terms of line count. Line count is an arbitrary and unimportant metric. Think of it in terms of what the method logically does. The best rule would be:

  • A method should do one thing.

Or, to put it a better way:

  • A method should have only one reason to change.

(Still channeling Uncle Bob here, I've been hitting the Clean Code pretty hard lately.)

Combine this with other logical rules, such as:

And, in general, you end up with very small methods. There are exceptions to that, however. In many cases the "one thing" is expressed in one line of code, maybe two or three. But it's simple and expressive code and it's clear what that "one thing" is. (And the name of the method should, of course, clearly reflect that one thing.)

Sometimes, however, "one thing" is a longer sequence of steps. Perhaps you have a method encapsulating a single atomic process in your domain, but that process happens to be composed of a dozen or more steps. Each step would be its own "one thing" and it will probably internally have other "one things" in other methods and so on.

Each individual method does "one thing." But the higher-level encapsulating methods which aggregate the smaller steps into larger atomic processes get a little longer because their "one thing" is made up of many smaller "one things." It's rare, but it happens. And the usual result when it happens is one method which is nothing more than a sequence of method calls. (This isn't to say that this is an excuse for long methods. Carefully examine the logic of the code to determine if re-factoring the larger methods actually would make sense.)

This larger encapsulating method is often a result of applying the Transaction Script Pattern to business logic. There's a single step, responding to a single request, which consists of a multi-step process within the business logic.

Methods should be small. They should be even smaller than that. If they're not, examine them closely to determine why. If there's more than one level of indentation, that's usually a sign that it should be re-factored. If there are multiple checks and balances from the inputs, it probably could use some re-factoring. If the method is doing more than one thing or has more than one reason to change, it should definitely be re-factored.

Community
  • 1
  • 1
David
  • 208,112
  • 36
  • 198
  • 279
  • 2
    I'm not in the "*methods* should be small" camp, partly because small methods means lots of argument passing and additional cruft that adds confusion rather than subtracting. I do beleive that chunks of code that are coherent *should* be clearly grouped together, which is what people are using methods to do. But grouping can be established by other methods, including simply putting the code in a block " { ... } " with a simple comment at the front as to what the code block does. That lets you group the code without necessarily passing tons of parameters. – Ira Baxter Jul 10 '12 at 12:53
  • 2
    @IraBaxter: Well, there's a qualifier. Methods _should_ be small, but they don't *have to* be small. Particularly not at the expense of readability and maintainability. As you indicate, that can be a problem. Blindly reducing methods without improving the code doesn't help anybody. The code should logically and intuitively make sense, that's really the ultimate rule. Everything else is secondary in support of that goal. To your example, if reducing the size of methods does lead to increasing the number of arguments then it was in vain. They were reduced, but they weren't _decoupled_. – David Jul 10 '12 at 13:00
0

It's usually a very good idea to split large functions in smaller ones.
It's not a problem if they are well designed and it's easy to understand what is going on. But the larger the function, the harder it becomes to do so. Keeping functions simple will allow you to track problems easier later on.

Alin Huruba
  • 35,481
  • 2
  • 12
  • 9
0

Early programmers used to limit their method lengths to just 10 lines of code. If their method was any longer, than they split it up. This is an outdated programming style, and is no longer widely used. Most experts agree that methods can be as long as it makes sense for them to be. (by that, it means they should not be broken up as long as there is no logical breaking point)

Personally, I strive for shorter methods. But that being said, I do not make a point of breaking up a long one unless there is an obvious logical breaking point. The only reason for this is that it just makes my code easier to read and debug; especially if method names are descriptive.

dykeag
  • 554
  • 3
  • 11
  • Early programmers? I've been coding since 1968 and am probably close to Neandrethal, but I don't recall any admonition to code 10 line "methods". Style arguments have been going since well before most the current programmers were born, and each of has generally arrived at something workable. – Ira Baxter Jul 10 '12 at 12:45
  • "Early programmers" is a phrase my professor used when communicating this information to us. I'm sure this does not mean it was a standard early on in the days of programming; but rather an early school of thought about programming. – dykeag Jul 10 '12 at 19:35
  • There's a zillion schools of thought about programming, from both old fogies and johnny-come-latelys. I think my objection is the apparant assertion that any one of them was/is dominant in a useful way. – Ira Baxter Jul 11 '12 at 15:31