The hidden benefit of writing short methods

A method should do only one thingQuoting Uncle Bob:The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be …

A method should do only one thing

Quoting Uncle Bob:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.

From one of Martin Thompson’s presentations I have learned another – more easily available and intuitive – method of judging wether a method is small enough. What you are supposed to do is to physically cover the part of your screen on which the method is displayed with your hand. If you can’t do that, then it means that your method probably is not small enough and you should consider refactoring it.

The obvious advantages that you gain by following these rules are improved readability and maintainability of your code.

But there is one – less obvious – benefit of writing short methods

And that is that Java HotSpot VM’s JIT compiler uses a compilation technique which is called inlining. 
What the compiler does is it substitutes the body of a method into places where this method is invoked thus saving the cost of calling the method. 
Current default for HotSpot is set at 35 bytes, which means that the compiler will inline a method if it contains less than 35 bytes of bytecode.

How do I know the bytecode size of a given method?

The easiest way is to dump the class file containing your method with:
javap -c mypackage.MyClass

which returns bytecode of decompiled class and the size of each method (well actually the size is equal to the byte offset of the last instruction – you can read more about javap HERE).

You May Also Like

After WHUG meeting

Here are the slides from the talk a gave yesterday. If you have any questions, please ask. Here are the slides from the talk a gave yesterday. If you have any questions, please ask.

Micro services on the JVM part 1 – Clojure

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.