9.3. Popular Java and Groovy Code Quality Analysis Tools
There are many open source tools that can help identify poor coding practices.
In the Java world, three static analysis tools have stood the test of time, and are widely used in
very complementary ways. Checkstyle excels at checking coding standards and conventions, coding
practices, as well as other metrics such code complexity. PMD is a static analysis tool similar to
Checkstyle, more focused on coding and design practices. And FindBugs is an innovative tool issued
from the ongoing research work of Bill Pugh and his team at the University of Maryland that focuses
on identifying potentially dangerous and buggy code. And if you are working with Groovy or Grails,
you can use CodeNarc, which checks Groovy coding practices and convention.
All of these tools can be easily integrated into your build process. In the following sections, we will look
at how to set up these tools to generate the XML reports that Jenkins can then use for its own reporting.
9.3.1. Checkstyle
Checkstyle^1 is a static analysis tool for Java. Originally designed to enforce a set of highly-configurable
coding standards, Checkstyle now also lets you check for poor coding practices, as well as overly
complex and duplicated code. Checkstyle is a versatile and flexible tool that should have its place in
any Java-based code quality analysis strategy.
Checkstyle supports a very large number of rules, including ones relating to naming conventions,
annotations, javadoc comments, class and method size, code complexity metrics, poor coding practices,
and many others.
Duplicated code is another important code quality issue—duplicated or near-duplicated code is harder
to maintain and to debug. Checkstyle provides some support for the detection of duplicated code, but
more specialized tools such as CPD do a better job in this area.
One of the nice things about Checkstyle is how easy it is to configure. You can start off with the Sun
coding conventions and tweak them to suit your needs, or start from scratch. Using the Eclipse plugin (or
even directly in XML), you can pick and choose from several hundred different rules, and fine-tune the
settings of the rules you do choose (see Figure 9.1, “It is easy to configure Checkstyle rules in Eclipse”).
This is important, as different organizations, teams and even projects have different requirements and
preferences with regards to coding standards, and it is better to have a precise set of rules that can be
adhered to, rather than a broad set of rules that will be ignored. It is especially important where large
legacy code bases are involved—in these cases, it is often better to start off with a more limited set of
rules than to be overwhelmed with a large number of relatively minor formatting issues.