As you probably know, you should keep the methods (functions, procedures, …) in your code short and have each of them do only one thing. While hardly anyone opposes this rule, we still find a large number of long methods in the code bases we analyze. I believe this is because many developers are not aware of all the benefits that short methods have. The common argument is that short methods are somehow »easier to understand«. But that seems not convincing enough to keep methods short in practice. In this post I describe the advantages of short methods, which are:

• Comprehension
• Documentation
• Reuse
• Testing
• Profiling

Comprehension

The most prominent argument is that short methods are easier to understand. So this point may not really surprise you. As a rule of thumb we suggest that methods should never be longer than one page in your IDE. That is, you should be able to read and understand the methods without having to scroll up and down. You might argue now that you can decrease the font size to fit more lines on one page but I think you get the point. ;-)

Documentation

One advantage that is often overlooked is that shorter methods allow you to give descriptives name to code blocks. While a long method forces you to use a single and often too general name for all the code that belongs to that method, shorter methods allow you to use multiple descriptive and more precise names for shorter code blocks. In many cases, long methods are subdivided by comments to overcome the problem that individual code blocks do not have a name. Hence, shorter methods improve the documentation of the code out-of-the-box.

The code above shows an example taken from the ConQAT code. The method hardly requires any comments, because the methods, that are called, document the method. In this particular case, analyzing an element (a source code file) consists of the following three steps:

1. Get the tokens.
2. Filter the tokens.
3. Analyze the tokens.

If these steps were not individual methods but all part of analyzeElement, it would definitely not be as easy to understand what is happening.

Reuse

One of the major obstacles in software maintenance are code clones. And in many cases, clones are created, because you want to reuse only a part of an existing method but cannot reuse the method as a whole. So you copy, paste, and modify the existing method to fit your needs. This results in new code clones and all the risks that are associated with them. If your long method was in fact a number of shorter methods, the probability is much higher that one of these methods provides exactly the functionality that you need. You can reuse the corresponding code by simply calling the method. Consequently, short methods help you to avoid code clones and keep the redundancy in your code base low (not surprisingly, the Extract-Method-Refactoring is the first choice to get rid of code clones).

Testing

Unit tests are often done on the method level, that is, one or more tests check the functionality of a single method. This gets more and more complicated the longer the method to test is. In most cases, long methods also contain a significant number of conditionals, making things even worse. If your objective is to test all potential branches, you need a lot of test code to test a single method. A short method would make that much easier. In addition, a failing test gives you much more precise information about what went wrong if the method that was tested has 5 lines compared to having 100 lines. If you happen to measure your test coverage on the method level, shorter methods make the coverage results more precise (if your code is all in one long method, there would be only 0% or 100% test coverage).

Profiling

Finally, you may need to profile your application because somewhere time is lost and things are going slow. Most profiling is done based on methods, that is, the tool measures how much time each particular method requires. This information gets more valuable the shorter the methods are. If you know that your 100-line method requires all the time, you still need to manually find the specific location inside these 100 lines. This is much easier if methods are short.

Summary

Because of the various downsides of long methods, method length is one of the central code-structure metrics measured by our tool Teamscale. I hope these arguments convince you that keeping methods short is generally a good idea. If you now wonder how short your methods should be, we totally agree with Clean Code author Robert C. Martin: as short as possible! But since that is not always helpful and hard to measure, our general advice is that methods should not be longer than 40 lines of code—roughly the code that fits on one screen. Longer methods should be the exception. It is also advisable to keep the majority of your method in the ten lines and below range. To give you an idea how long methods are in our own code, we have analyzed the methods in the open-source ConQAT engine. Of all 13,634 methods,

So, go ahead and refactor long methods. But as you know, don’t fix all of them at once.