Day 2: Write Shorter Methods

Hi, this is the second part of  a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

Today I will talk about a technique that made my code to improve in a fantastic way, probably more than anything else that I had tried before: writing shorter methods. The technique is so simple and so useful that I don’t understand why everyone isn’t REQUIRED to do this.

Why Short Methods?

The main idea behind using short methods is that you keep yourself from doing too much in any one location. If you ever tried to write more than a few lines of code in any method you most certainly were mixing levels of abstraction, which ultimately leads to methods that are difficult to understand and to maintain.

For example, consider a method that updates information about employee salaries. If the same method is writting information to the database, it is trying to do two things at once. So, if you change the code to update salaries you will need to change the method. The same happens if the database changes. That is, if you add different responsabilities to a method you make it more unstable, just because there are more reasons for it to change.

On the other hand, when you have methods that are really short, you are required to go straight to the central issue that you are trying to solve. No space for secondary concerns exist.

It all boils down to the issue of using the right abstraction level. With long methods, abstractions are not well maintained because you may spend too much space with instructions that are a level bellow from where you are working.

What is Wrong with Long Methods?

Long methods are bad in a lot of ways. It would require a lot of space to write all that I don’t like about long methods, but here are some of the most important issues:

  • Long methods are difficult to understand. With size comes complexity, and if you are maintaining code where methods are huge, you need to be very careful about side effects. Remember, all local variables are in practice global inside the scope of a method. If you have lots of things going on, it is difficult to see what the collateral damages might be.
  • Long methods are hard to optimize. Even after you make you long method correct, it is difficult to make the changes necessary to optimize it. For example, if you decide that a certain variable is used in a wrong way, you still need to spend time proving that everything works after a change. A simple change like this may create bugs that you will take a long time to notice.
  • Long methods obscure the intention of the code. Since in a long method you are certainly going into more detail than necessary, you are creating code in two or more levels of abstraction. This also contributes to make the code difficult to understand.
  • Long methods can slow down your code. This is true if you are using a manged language such as Java or C#. These languages use JIT engines that transform methods into executable code. However, a long method takes longer to convert into native code than a short one. Also, long methods will have parts that may not be used frequently, so there is no justification for compiling it, other than the fact that it is part of the long method.

How short is short enough?

This is a subjective issue of course, and as such there is no clear answer. However, I like the guideline that 10 lines is already too much. This is a guideline used by Robert Marting in his books. I think it is a very reasonable rule of thumb, but for me it is more of an upper limit. Methods with 3 to 6 or 7 lines are even more interesting, because they condense the main ideas of the abstraction you are trying to convey.

Additional Advantages

Short methods also make some other things easier, like creating good method names. Since the method is allowed to do only a small number of actions, it is easier to figure out what it is doing — and thus given it a proper name.

Another area that is positively affected by short methods is testing. It becomes much easier to see the cases that should be tested when there is just a small number of operations involved. Instead of trying to cast a big net over a sea of options, testing small method tends to be a much more focused experience.


I think that this item covers a practice that, by itself, has the potential of making your code much better. Writing small methods helps with separating the different concerns of your application. It gives a simple guideline that helps on making decisions about how code should be organized. It also helps in eliminating many of the problems in the areas of testing, revising, and maintaining existing code.

Additional Reading

  • The first book that really showed me the importance of small methods was Clean Code, by Robert Martin. It covers a lot of ground in matters of code organization, which I believe are essential.
  • Another book that explains why long methods are bad is Effective C#, which will convince you that such methods can slow down managed code in languages like C#.

Go to the next post of the series:

Similar Posts:

About the Author

Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.

10 Responses to “Day 2: Write Shorter Methods”

  1. Its early in your series, but I’d suggest as one step:

    Learn Functional Programming – even if you intend to keep on with OOP.

    By Shaun on May 27, 2009

  2. @Shaun, thanks for your suggestion. I was certainly thinking about something along these lines.

    By coliveira on May 27, 2009

  3. Great article!!! Looking forward to the next 28 days!!!

    Thank you!!!

    By Kjartan Ólason on May 28, 2009

  4. Last 2 articles can gear as well as steer my programming career, which I will take up soon.

    Eagerly, looking for another 28 articles.

    As a supplement to article 1;I suggest “Code Reading: The Open Source Perspective
    By Diomidis Spinellis”

    Many Thanks.

    By Ram kishore on May 28, 2009

  5. Informative.

    Some where I read that a function should be as lengthier as that it could be seen in monitor without scrolling the page! :)

    By Veera on May 29, 2009

  6. One other major advantage of writing short methods is code reutilization – you’re much more likely to reuse short method with single intent than long methods that do more than one thing. It leads to more reusable code and to not breaking DRY.

    By Eugen Paraschiv on May 29, 2009

  7. Good advice (p.s. don’t forget to spell check your posts!)

    By Matt on May 30, 2009

  8. Interestingly enough, there is a TOO short point for methods as well, where you have broken up your code so much that it is difficult to follow the flow of control between methods. While writing shorter methods is good when it is a technique to improve reusability and readability, it must be done consciously. It is not a silver bullet.

    By Katie on Jun 1, 2009

  9. That reminds me of a couple of methods 2 screens’ long in the project I’m working on right now. Try to change anything there…

    First thing before I pick up on such mnethods is refactoring. Unfortunately time is money, and we all lack of time, so that’s not always possible. Also, refactoring means thourough testing – time again…

    That all brings the question – do I really have to write so long method? Please ask it yourself when you’re coding. I’m sure you’ll save lots of time the person who needs to maintain it.


    By Jaroslaw Dobrzanski on Jun 2, 2009

  10. @Katie: I agree that there are exceptions to this rule, but I think it is much harder to make a mistake when methods are short and to the point.

    By coliveira on Jun 4, 2009

Post a Comment