chunk of code that's called only once - merits own method?

Question

From observing source code for various Android applications (not written by me), I noticed a pattern of placing certain pieces of code into their own methods, although there really isn't any code reuse, because those methods are only called once throughout the entire application.

Up until now I had a rule of thumb which dictates that if a piece of code is used twice or more in the application code, then it merits its own method, simply for reason of eliminating code redundancy.

But seeing those neatly broken out chunks of code into own methods (and own method calling overhead), I am beginning that maybe I am missing something.

Other than for documentation purposes, what other reasons can justify putting only 4 lines of code (that are called only once!) into own method?

Answer 1

There are a few reasons I can think of, though admittedly there's some overlap:

• It helps make your code self-documenting.
• It makes (unit) testing easier.
• It helps stop you ending up with methods which are hundreds of lines long.
• You might want to use that code somewhere else in the future.

Of course, all of this relies on the assumption that those 4 lines of code are related, and performing a single function. I find that a good rule of thumb is: if you can't think of a name for it, it probably shouldn't be a method.

Answer 2

See the justifications as given for the Compose Method refactoring.

Answer 3

documentation and readability are very good reasons to put code into methods, even if those methods will only be executed once. Some applications might have a bunch of logical steps to complete on startup....would you rather have all that code jumbled in one init method, or an init method that calls methods that are properly named?

Answer 4

Three reasons to start with:

• You can test it in separation from anything else. (This may end up going against the mantra of only testing public APIs, but that's fine by me. It's annoying if I have to make a method package-level instead of private in order to test it, but I'd rather do that than have to test a huge lump of logic in one go.)
• You can build a more complicated method from simple methods, where the whole of the complicated method is at a single abstraction level, without specifying details. Reading the high-level method means just reading the names of the building blocks it's composed from; you can then dive into just the details you're interested in if you need to.
• You can write methods which each do one thing well, and name and document them in an obvious way

Of course this can be overdone, but it can definitely be useful.

Answer 5

It hopefully facilitates cleaner code, and it should be easier to test.

You mention method-calling overhead, but that should be of no concern if the method is only called once.

Answer 6

Readability is my big reason for such coding behaviour.

If I'm staring at a long code listing, looking for a specific procedure or a section of code, it might not be immediately obvious where that specific procedure or section of code is.

Why do we write books in paragraphs and chapters? Why do songs have stanzas/verses, choruses and bridges? Because it's easier to take in a big idea in small, highly specific, chunks.

As much as software development is all about driving efficient, clean code that gets the job done as quickly and elegantly as possible. It also has to be readable by the humans who are going to maintain it.

At least, that's my interpretation.

Answer 7

Java VM's in general have a limit on the maximum size of method that will be eligible for inlining. Extracting infrequently called code may grease the wheels so to speak. Can you point out examples?