At the moment I am working on a Groovy/Grails project (which I'm quite new in) and I wonder whether it is good practice to omit the return keyword in Groovy methods. As far as I know you have to explicitly insert the keyword i.e. for guard clauses, so should one use it also everywhere else? In my opinion the additional return keyword increases readability. Or is it something you just have to get used to? What is your experience with that topic?

Some examples:

def foo(boolean bar) {
    // Not consistent
    if (bar) {
        return positiveBar()

def foo2() {
    // Special Grails example
    def entitiy = new Entity(foo: 'Foo', bar: 'Bar')
    entity.save flush: true
    // Looks strange to me this way
  • There's a similar issue in Perl: a function returns the last evaluated expression in tbe absence of a return statement. Personally, I always use the explicit return, but I don't know Groovy. Jun 11 '12 at 17:57
  • 2
    Personally I'd use the implicit return only when it's perfectly clear. toString is a typical example: it's a one-liner and the value computed is obviously the return value. But then again, I haven't programmed enough Groovy to know if that fits into what the larger community thinks. Jun 12 '12 at 6:06

I certain would add the return, as it makes the intention clearer to any person (including yourself) who may come and update/maintain the code later on.

Otherwise it might look like a typing error.

The other thing is to remember to declare functions/closures that are expected to return a void as 'void' - again to make it clearer to future maintainers what you are trying to do.


Clarity is King.

Do what is most clear to the fellow programmer who has to read your code after you write it.


Here's an argument for omitting the return statements (Source):

An Understated Feature in Groovy


I have worked with Groovy for awhile, but have been averse to one feature: the implicit return of the last expression evaluated. For example:

def getFoo() {
  def foo = null
  if (something) {
    foo = new Foo()
  foo // no 'return' necessary

In the above code, I would use return because it felt safer to me. I tended to agree with Eric's post (with respect to explicit returns).


I get it now, and it's all thanks to the enhanced collection methods in Groovy.

Consider the collect method. It transforms a list by applying a function. In pseudocode:

[ a, b, c, d] => [ f(a), f(b), f(c), f(d) ]

With that in mind, here's another example:

class Composer {
  def name
  // def era, etc

def list = [ 'Bach', 'Beethoven', 'Brahms' ]

// the closure returns the new Composer object, as it is the last
// expression evaluated.

def composers = list.collect { item -> new Composer(name : item) }

assert 'Bach' == composers[0].name

The idea is simply to build a list of Composer objects from a list of strings. As noted in the comment, the closure passed to collect uses the implicit return to great effect. At one time, I would have taken 3-4 lines to express that idea.

But now, this code is not merely concise: it is truly elegant. Very reminiscent of other languages such as Python.

The Take-Home Message

There are many lists of excellent Groovy features. However we rarely see 'implicit return' listed. I'm a fan: it greases the wheels for other features.

I realize it is available in many languages: I just haven't used it in Groovy. I suspect in a few weeks I won't be able to live without it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.