This is the fourth in a series of posts on the generating and displaying source code metrics.

Checkstyle

Checkstyle is a handy little tool for checking if your Java code adheres to the standards of your organization. Don’t have a custom set of standards yet? Fear not because they scan for the Sun Code Conventions which should tide you over until you can tune them to your specific needs / wants.

Don’t care about how your code looks? You should. Not only does uniform code make it easier to ramp up up new developers on how to write code that integrates cleanly into the project as a whole but it also makes sure that the company policies on how to write code are clearly disseminated. In java this would settle the age old ‘where do I put my braces’ question for instance. Every organization will have different policies around these sorts of things so you cannot just fire-and-forget with Checkstyle. Instead you must look at the responses and see if they are valid in your context. For example, you may not care that a package does not have a package documentation file. Checkstyle does though, and will report it though and report it great gusto.

Here is the ant task to incorporate Checkstyle into your build system

<!-- checkstyle -->
<target name="checkstyle">
 <taskdef resource="checkstyletask.properties"
          classpath="${metrics.dir.lib}\\checkstyle\\lib\\checkstyle-all-4.2.jar"/>
 <checkstyle config="${metrics.dir.lib}\\checkstyle\\checks\\sun_checks.xml"
          failOnViolation="false">
  <fileset dir="${dir.source}" includes="**\\*.java"/>
  <formatter type="xml" toFile="${metrics.dir.report}\\xml\\${report.name}"/>
 </checkstyle>
</target>

Variables:
metrics.dir.lib – Tell ant how to find the checkstyl task in a decoupled manner. I try not to put these in the main ant lib dir.
metrics.dir.report – The place where you want the report put. In this case, my reports dir has ‘xml’, ‘xsl’ and ‘html’ dirs for organization of the various parts of the report generation process.
report.name – I call this target for each module I am collecting metrics for, so I pass in the name of the report as a parameter to it. Feel free to hardcode if that suits you better.
dir.source – Since PMD works on the actual sourcecode, you need to specify where the top-level dir that contains it. Note that if you have a package called org.agoucher.metrics, it would be the dir that contains the ‘org’ dir.