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.

Conclusion

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:

• Day 3: Keep A Programming Diary
• Day 4: Learn a New Programming Language
• Day 5: Write a Unit Test Before Coding

Similar Posts:

• The Beauty of Short Methods
• Reducing the Size of Parameter Lists
• Should we Write Generic Code?
• When in Doubt, Create an Interface
• Day 13: Write Functions in a Functional Style