I am firmly convnced that the easiest, and most reliable way to inprove software quality is to inject quality checks/balances/policies/whatnot into the developnment process. Thr further upstream the better infact. That way, when it lands at the test group’s door it is already of a high quality. One useful check is the use of code quality metrics. The main one people talk about these days is code coverage, but there is also ones to make sure that the coding standards are followed, that there isn’t a lot of code duplication or the overabundance of developer notes (TODO, FIXME, etc). I started to play with QALab as a way of collecting and aggregating these stats, but could not get the XSLT to work, so I just skipped the aggregation and made individual reports which get client-side tansformed into HTML.

This is the first in a series of posts which have the ant targets and javascript to generate and report on source code derived quality metrics.

FindBugs

FindBugs searches through you compiled java classes and/or jars looking for common defect patterns. A full list of the patterns is available on their website.

<target name="findbugs">
 <property name="findbugs.home" value="${metrics.dir.lib}\\findbugs"/>
 <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
  <classpath>
   <pathelement location="${findbugs.home}\\lib\\findbugs-ant.jar"/>
  </classpath>
 </taskdef>

 <findbugs home="${findbugs.home}" output="xml:withMessages"
           outputfile="${metrics.dir.report}\\xml\\${report.name}"
           debug="false">

  <!-- directory to analyze -->
  <class location="${dir.dist}"/>

  <!-- remove the jars we don't want analyzed -->
  <auxClasspath>
  <fileset  dir="${dir.3rdparty}">
   <include name="*.jar"/>
   </fileset>
  </auxClasspath>

  <!-- teach it where the source is -->
  <sourcePath path="${dir.source}"/>
 </findbugs>
</target>

The variables mean:

  • findbugs.home – The place where you installed FindBugs
  • 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.
  • dir.3rdparty – Our application uses a number of 3rd party libraries I want ignored by the analysis, this is how it is done.
  • dir.source – In order to nicely link the issues encountered with their occurance in the code, you need to specify where the top-level dir that contains your source is. Note that if you have a package called org.agoucher.metrics, it would be the dir that contains the ‘org’ dir.

Note: This target should ideally be dependent on whatever target your build.xml has for the actual compilation of your code. Mine isn’t because I am trying to make it as generic as possible and that target is named different things in the different projects we have on the go now.