97 Reasons to use IDEA for Groovy Development

In preparation for the Groovy IDE Shootout at Groovy.MN next Tuesday, I decided to crack open my IDEA settings pane today and see that additional inspections the JetGroovy plugin defines for IDEA.

Holy crud... there are 97 Groovy Inspections (98 if you count the ones in the svn repo). Most of these are not turned on by default, so it may be worth the effort to go through and turn them on. I've found that following the inspections' advice makes my code a lot Groovy-ish, it does a good job of flagging Java idioms and converting them into the equivalent Groovy code.

Here's a rundown of the more exciting ones:

Control Flow - "Conditional expression can be conditional call" teaches you to use ?. instead of conditionals. Nice. "Conditional expression can be elvis" teaches you to use ?:, which in my opinion is confusing but some people like it. And "'return' statement can be implicit" reminds you the return keyword is optional. There's also a bunch of other inspections similar to the Java ones, like "Constant if statement", "Loop statement that doesn't loop", and "Redundant conditional expression".

GPath inspections - "Getter call can be property access" turns all your foo.getBar() into foo.bar invocations. The autofix on this makes it really helpful. The same inspection applies to setter calls, List get/sets, and Map puts/gets. I use these all the time.

Potentially confusing code constructs - The same inspections from Java, such as "Statement with empty body", "Negated conditional expression", "Overly complex arithmetic expression", and "Pointless boolean expression". I find the pointless expressions inspections helpful, especially during refactorings.

Validity issues - The "Method with inconsistent returns" inspection will catch some type errors that aren't possible in Java. "Unreachable Statement" is helpful too.

Threading issues - I've professed my love for the Java threading inspections before, and the plugin brings many of them to the Groovy platform. There are 18 inspections in this category, and I've found "Unsynchronized method overrides synchronized method", "Synchronization on non-final field", and "Synchronization on variable initialized with literal" to be invaluable.

Error handling - Nothing especially Groovy here, but "Unused catch parameter", Empty catch/try/finall block, and the rest are helpful.

Assignment issues - Again, many standard inspections from Java, such as "Assign to Method Parameter", "Silly Assignment", and "Result of Assignment Used". These are mostly good for keeping up with coding standards or just flagging your Friday afternoon code as crappy.

Method Metrics - When my "Overly complex method", "Overly long method", and "Method with too many parameter" inspections show up, I like to view the version history to find the culprit and then stink eye them all week in the lunch room. I suppose your work environment could be different.

Probable bugs - I've never actually had these show up, but I suppose inspections like "Divide by zero", "Infinite recursion", and "Result of object allocation ignored" could help someone out there who despises unit tests.

I opened my settings and turned them all on, and now I'm slowly turning off the ones I don't like (or that give false positives). Seems like a good plan.

The full list of inspections is available on the JetGroovy wiki, and don't forget to download the IDEA RefCardz from DZone. I heard the author is a nice guy.