Short methods FTW

Marc Mueller

Some 5 years ago, I got my first intern job in a small startup. We were building a computer vision prototype in Matlab, and my assignment was to write C/C++ code that was supposed to do different types of transformations on video frames. I wrote a 300-lines-long monstrosity of a method that was doing all kinds of transformations and calculations on a matrix. It worked, and I was happy. Then my boss came to me and said:

Every method that you write should be less than 25 lines long.

And I laughed, I laughed hard, right in his face. I was such a plonker!

And let me tell you something, 25 lines make one big, long method. Actually, most should be much shorter, around 10 lines, maybe even less. 25 lines should be the upper limit. And why is that?! Well, here are some of the reasons:

• First of all, it fits easily on your screen, so it’s easy to read.
• Its purpose can be expressed in one simple sentence, and that makes it (in most cases) easy to understand.
• It doesn’t need comments, because it does only one thing, and that thing can be described within its name.
• It’s easy to test.
• And lastly, because Uncle Bob said so.

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” — Robert C. Martin

However, not all short methods are good. For example this one:

This one is horrible in so many ways that it hurts my eyes to look at it.

But pretty much every long method is bad.

Long method bodies are a classical code smell: it’s not in itself a problem, but it’s an indication that there’s probably a problem there.

Joachim Sauer (has nothing to do with this Joachim Sauer, I think 🤔)

One thing that’s mind-boggling is that the vast majority of developers knows that the long methods are bad, but very few actually follow this rule. Quite often, I see good developers writing huge methods because “It’s a UI” or “It’s in a test” or “It’s Java ✋”. And at first glance, it doesn’t look that bad. Code is well organised and each line logically follows the previous one. That’s because the developer who has just written that code has its context and understanding in his head, so he doesn’t need to get it from the code. When another developer tries to change that part of the code one year after it’s been written he/she is …

going to fail. Why?

1. Because there is no time to invest in proper analysis of that method. (New feature needs to be done by yesterday).
2. There are no tests to support refactoring. Not because it’s hard to cover a 100-lines-long method with tests (btw. it is hard), but because it’s much easier to split it into 10 methods, and write tests for each of them. Therefore, there is a good chance that that person didn’t even try to test it. And if he/she did, it’s likely that our developer would be making changes on 10 short methods.
3. Misleading comments are everywhere. First of all, there has to be at least a couple of comments in a long method (it’s really unprofessional to write a long incomprehensible method without comments 😄). And it’s quite probable that code has already been changed, but developers are really scared of changing other people’s comments, so comments will stay the same. They will be sitting there, telling you a story of some other badly written code.

So please, for the love of Uncle Bob, write your methods short.

P.S. I promise that I will refactor long methods in my projects on GitHub. 🤞

Thanks for reading! If you enjoyed this story, please click the 👏 button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.