Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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()
    }
    negativeBar()
}

def foo2() {
    // Special Grails example
    def entitiy = new Entity(foo: 'Foo', bar: 'Bar')
    entity.save flush: true
    // Looks strange to me this way
    entity
}
share|improve this question
    
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. –  Keith Thompson 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. –  Joachim Sauer Jun 12 '12 at 6:06

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer

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

An Understated Feature in Groovy

Background

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

Revelation

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.

share|improve this answer

Clarity is King.

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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