Note that in the last example, we used a Checkstyle ruleset that we have uploaded to a Sonar server
(defined by the ${sonar.url} property). This strategy makes it easy to use the same set of Checkstyle
rules for Eclipse, Maven, Jenkins, and Sonar.
Recent versions of Gradle also offer some integrated Checkstyle support. You can set up Checkstyle
for your builds as shown here:
apply plugin: 'code-quality'This will use the checkstyle ruleset in config/checkstyle/checkstyle.xml by default. You can
override this with the checkstyleConfigFileName property: at the time of writing, however, you
can’t get the Gradle code quality plugin to obtain the Checkstyle rules from a URL.
You can generate the Checkstyle reports here by running gradle checkstyleMain or gradle
check.
9.3.2. PMD/CPD
PMD^3 is another popular static analysis tool. It focuses on potential coding problems such as unused
or suboptimal code, code size and complexity, and good coding practices. Some typical rules include
“Empty If Statement,” “Broken Null Check,” “Avoid Deeply Nested If Statements,” “Switch Statements
Should Have Default,” and “Logger Is Not Static Final.” There is a fair amount of overlap with some
of the Checkstyle rules, though PMD does have some more technical rules, and more specialized ones
such as rules related to JSF and Android.
PMD also comes with CPD, a robust open source detector of duplicated and near-duplicated code.
PMD is a little less flexible than Checkstyle, though you can still pick and choose the rules you want
to use in Eclipse, and then export them as an XML file (see Figure 9.2, “Configuring PMD rules in
Eclipse”). You can then import this rule set into other Eclipse projects, into Sonar, or use it in your Ant
or Maven builds.