When we write code, it’s important to follow some rules, right practices, style rules, etc. However, sometimes it is not that simple. It is even more important when we work in a team, in which every member has his preferences. One way of improving this is adding a static analysis tool for the code.

In this guide, you are going to install and configure Codenarc to help you improve the quality of your Grails code, and you are also going to learn how to create a custom CodeNarc rule. CodeNarc analyzes the Groovy code and reports potential bugs and code problems.

To complete this guide, you will need the following:

To get started do the following:

or

The Grails guides repositories contain two folders:

To complete the guide, go to the initial folder

and follow the instructions in the next sections.

We are going to setup a multi-project build with a Grails application and a custom CodeNarc Rule as shown in the next image:

Check our Grails Multi-Project Build Guide, to learn more.

Current CodeNarc version (0.27.0) includes 348 rules divided in 22 categories:

And there are many more categories to check for duplicated imports, unused variables, unnecessary ifs,…​ And of course there’s a specific category for Grails rules.

Adding CodeNarc to our project is a simple task because there’s a Gradle plugin to do it.

Let’s modify build.gradle and add the following:

We encapsulate all the CodeNarc configuration in gradle/codenarc.gradle:

Then we need to create the rules file:

With this configuration we can just run the check task.

And we can open the test report to check the violations:

If you install CodeNarc in a medium-big size project, which has not use any static analysis tool before, you may have hundreds or event thousands of violations. It is possible that your team has not been careful enough while writing code. Moreover, it is likely that CodeNarc default configuration contains some rules you don’t agree with. Rules which might not be a good fit for the team.

My advice is to review all the violations, read their documentation and then decide if you want to disable them, configure with another option and finally fix and respect them.

Once the team decides the rules and the configuration the next step is to choose the thresholds to make the build fail. These thresholds allow having successful builds with some violations but, once we reach these levels, the build will fail.

To do that, just edit the build.gradle file:

With this configuration the build will fail once we reach these thresholds.

Although CodeNarc provides some rules specific for Grails, some times we may want to create our own rules.

In this example we’re going to create a rule to check that we use
grails.gorm.transactions.Transactional instead of @org.springframework.transaction.annotation.Transactional.
As you probably know the Grails @Transactional annotation is better because it doesn’t create a runtime proxy. It’s an AST Transformation that it’s applied during compilation time, so there’s no runtime overhead. There’s also other features that the Grails annotation provides and the Spring one don’t.

The rule checks our code. If we use the Spring annotation, it adds a new violation to the report.

Once we have created the rule and it’s available on the classpath, it’s time to add it to the Grails application.

Now we can create a service and use Spring @Transactional on it:

And the final step is generating the CodeNarc report:

As we can see we have a new violation because the rule we created as been applied.