Question

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?

Answer 1

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:

• A method should have only one level of abstraction.
• A method should follow the Law Of Demeter.

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.