Issue 132  7th August 2018

Groovy Developer Manifest

@musketyr has published a Groovy Developer Manifest.

I agree with one point heartily:

I will never use Map as an excuse not to create meaningful class

The abuse of Maps is one of the biggest problems that I see in Grails apps. The behaviour is reinforced by some internal Grails APIs. For example, GORM methods taking a Map to supply offset, max. Or the params object, which is an instance of GrailsParameterMap, but it is often manipulated as a Map and supplied to the service layer to methods expecting a Map parameter.

Please, let us all stop abusing Maps.

Creating Extra Method Supporting Named Arguments Using @NamedVariant Annotation

Another point mentioned in the Manifesto is:

I will use @NamedParam, @NamedDelegate and @NamedVariant instead of raw Map method parameters

Those transforms were introduced in 2.5.0 and are explained brilliantly by @mrhaki.

@ClosureParam Annotation

Another point mentioned in the Manifesto is:

I will use @ClosureParams for every Closure method parameter

This points to the Groovy docs which is the best explanation I found for @ClosureParams.

@ClosureParams parameter annotation is aimed at helping IDEs or the static type checker to infer the parameter types of a closure.

@DelegatesTo For Type Checking DSL

Another point mentioned in the Manifesto is:

I will use @DelegatesTo for every Closure method parameter with altered delegate

It helps the IDE and static compilation capabilities.

With this annotation we can document a method and tell which class is responsible for executing the code we pass into the method. If we use @TypeChecked or @CompileStatic then the static type checker of the compiler will use this information to check at compile-time if the code is correct. And finally this annotation allows an IDE to give extra support like code completion.