DDevelopment & Design

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).

— Previous article

Groovy, Callable and ExecutorService

Next article —

Typeclasses in Swift, Haskell and Scala

You May Also Like
DDevelopment & Design

Simple trick to DRY your Grails controller

Grails controllers are not very DRY. It's easy to find duplicated code fragments in default generated controller. Take a look at code sample below. It is duplicated four times in show, edit, update and delete actions:

class BookController {
def show() {
def bookInstance = Book.get(params.id)
if (!bookInstance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
return
        }
        [bookInstance: bookInstance]
    }
}

Why is it duplicated?

There is a reason for that duplication, though. If you move this snippet to a method, it can redirect to "list" action, but it can't prevent controller from further execution. After you call redirect, response status changes to 302, but after method exits, controller still runs subsequent code.

Solution

At TouK we've implemented a simple trick to resolve that situation:

  1. wrap everything with a simple withStoppingOnRender method,
  2. whenever you want to render or redirect AND stop controller execution - throw EndRenderingException.

We call it Big Return - return from a method and return from a controller at once. Here is how it works:

class BookController {
def show(Long id) {
withStoppingOnRender {
Book bookInstance = Book.get(id)
validateInstanceExists(bookInstance)
            [bookInstance: bookInstance]
        }
    }

protected Object withStoppingOnRender(Closure closure) {
try {
return closure.call()
        } catch (EndRenderingException e) {}
    }

private void validateInstanceExists(Book instance) {
if (!instance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
throw new EndRenderingException()
        }
    }
}

class EndRenderingException extends RuntimeException {}

Example usage

For simple CRUD controllers, you can use this solution and create some BaseController class for your controllers. We use withStoppingOnRender in every controller so code doesn't look like a spaghetti, we follow DRY principle and code is self-documented. Win-win-win! Here is a more complex example:

class DealerController {
@Transactional
def update() {
withStoppingOnRender {
Dealer dealerInstance = Dealer.get(params.id)
validateInstanceExists(dealerInstance)
validateAccountInExternalService(dealerInstance)
checkIfInstanceWasConcurrentlyModified(dealerInstance, params.version)
            dealerInstance.properties = params
saveUpdatedInstance(dealerInstance)
redirectToAfterUpdate(dealerInstance)
        }
    }
}