Coding standards facilitate a common understanding of a code base among a diverse group of developers. Just like the car maintenance market has been largely standardized (i.e. one can buy a new headlight for a Toyota made by Toyota or any number of other third-party vendors; moreover, one can buy this item at various stores not even affiliated with Toyota, making the replacement or enhancement process rapid) so too, can a code base’s “structure” become standardized, which permits various individuals to quickly assess behavior and modify as needed in a rapid manner.

While both human code reviews and peer programming can be effective in monitoring coding standards, they do not scale as well as automated tools. Not only do tools contain hundreds of rules (that are usually customizable), they can be run frequently without intervention.

In a Continuous Integration environment, a code analysis tool can be run anytime the repository changes. The tool can analyze an individual file (such as the one modified) or the tool can analyze the entire code base. What’s more, due to the Continuous Integration infrastructure, interested parties can be notified of coding standard violations instantly.

For instance, a popular code analysis tool for the Java platform is PMD. PMD has over 180 customizable rules in categories ranging from braces placement (i.e. for conditionals), naming conventions, design conventions (like simplifying conditionals, etc), and even unused code.

In Java, if a conditional only has one statement following it, braces are optional. The following code, for example, is completely legal in Java:

if(status)
  commit();

Some organizations, however, find this code dangerous, due to subtle behavioral effects that may occur if someone forgets to add braces when adding additional statements.

The following code is completely legal; however there is a subtle defect that could ensnarl an unsuspecting developer. Do you see it?

if(status)
  log.debug("committing db");
  commit();

PMD, however, with its handy dandy rule set, will find code that has the potential to cause these errors and signify them in a report.

Naming conventions are usually the first coding aspects defined by teams to follow as un-descriptive terse variable names and methods can be somewhat difficult to comprehend (especially if the original author no longer works for the company!). For example, the following method could stand a better name and the variables ‘s’ and ‘t’ are also quite unhelpful in the larger context (i.e. one can figure out their type by examining the top of the method; however, if they were named more descriptively someone wouldn’t be required to look back at the top of the method).

public void cw(IWord wrd) throws CreateException {
  Session s = null;
  Transaction t = null;
  try{
   s = WordDAOImpl.sessFactory.getHibernateSession();
   t = s.beginTransaction();
   s.saveOrUpdateCopy(wrd);			

   t.commit();
   s.flush();
   s.close();
  }catch(Throwable thr){
   thr.printStackTrace();
   try{s.close();}catch(Exception e){}
   try{t.rollback();}catch(Exception e){}
   throw new CreateException(thr.getMessage());
  }
}

Once again, PMD to rescue! Running PMD against this code would yield multiple rule violations for both the method name and those one character variable names. By default, PMD’s scanning lengths are set to 3; however, teams can modify these values for longer names if desired.

PMD can also facilitate in the simplification of code. For example, the following method, while syntactically correct, is rather verbose.

public boolean validateAddress(){
   if(this.getToAddress() != null){
	   return true;
   }else{
	   return false;
   }
}

Once this method is flagged by PMD, it can be made more straightforward like so.

public boolean validateAddress(){
	return (this.getToAddress() != null);
}

PMD can be run via Ant or Maven and, like most every other inspection tool on the market, PMD produces and XML report, which can be transformed into HTML. For example, the following report displays the violations for a series of .java files in the XDoclet code base.

PMD also contains a series of rules which can report complexity metrics like Cyclomatic Complexity, long methods and long classes. What’s more, PMD isn’t the only code audit tool available to Java developers. CheckStyle is another open source tool with extensive documentation and Ant and Maven runners capable of producing HTML reports.

FxCop is a similar tool for the .NET platform with a myriad of rules and reporting capabilities; additionally, PyLint is available for Python.

By continuously monitoring and auditing code, corrective action can be taken early and often, thus avoiding long term maintenance issues and reducing the chances of introducing defects.