Programming Grails - Cdn.oreilly.com

def strings = []
but when the right side is a method invocation, I’ll type the left:
List strings = someMethod('Hello', 'Groovy', 'World')
and I often add the generic type even though Groovy ignores it—again as a selfdocumentation
practice and not because it has any other runtime effect. The same goes
for the return type and parameter type(s) of methods; if it’s void, I specify void some
Method(...) instead of def someMethod(...), so the caller knows that there’s nothing
being returned.
each is a convenient way of looping, but I rarely use it, because it has almost no benefit
over the for/in loop. For example, I would use:
for (string in strings) { ... }
instead of:
strings.each { string -> ... }
because they’re equivalent, basically the same number of characters, and both are nullsafe.
And the for loop has the benefit that you can break out of it if there’s a reason to
stop looping, whereas each cannot, because returning from the closure that you pass to
the each method returns from the closure, not each.
Of course, these are arguments about preferences—there’s no right or wrong here. And
I will certainly drop the type of a method parameter if it makes testing easier by letting
me substitute a more convenient value that uses duck typing.
Closures Versus Methods
Another example of being “too groovy” is using a closure as a method where you don’t
use any features of the closure. If you don’t set the delegate or use any other closurespecific
feature, then there’s no reason to use:
def foo = { ->
...
}
instead of:
foo() {
...
}
and, in fact, using the method has the not-insignificant benefit of letting you specify the
return type. Plus, things like AOP and method proxying that aren’t Groovy-aware won’t
work at all with closures, because they’re only treated like methods by Groovy—they’re
just public fields and are ignored by Java.
32 | Chapter 1: Introduction to Groovy