Increasing code quality is something that is currently being driven hard in our project. I am a big fan of weeding out code to make way for better smelling things like patterns and easily unit testable code. Many people have attempted to quantify code quality using metrics and a variety of tools to enforce these metrics. Checkstyle is one of these tools that we employ to encourage code quality (I qualify this because using these tools do not automatically equate to high quality code).

If you haven’t heard of it before, it’s a tool that helps to enforce coding standards in your project (and you should read more here). It can be used (and abused by project nazis) to enforce all types of coding standards from the most mediocre of coding formatting standards (have these people not heard of Jalopy?) to preventing code that is known to be poor design or quality from being added.

Take the following block of code which can be picked up by the IllegalInstantiation check:

// code that creates a new and unnecessary boolean object
Boolean isRedundant = new Boolean(true);

Although the JDK allows you do this, it is preferred that the following is used instead:

// code that reuses the same reference as Boolean.TRUE
Boolean isRendant = Boolean.valueOf(true);

Code formatting standards aside (still a very useful item for consistency and a whole another blog entry together), I believe the biggest value that checkstyle can bring are the custom checks that can be (easily written and) added for a specific project. The value behind custom checks (at least to me) is an obvious one. As a project ages over time, certain standard design patterns are used to approach a particular type of problem. Part of the induction cost of new programmers to a team is the knowledge transfer that happens over time as they are gradually exposed to all of the code base and learn these implict patterns that are littered throughtout the code. Quantifying these standards as custom checks is a less costly, and more reliable way ensuring new programmers do not violate these implicit standards, and more importantly can instantly gain the knowledge from the lessons learned by the current team.

On the project I am currently on, I contributed a custom check as a sanity check to ensure that whenever a session (think of a database connection) was opened, a corresponding close was called within the same method scope (with the intention of minimising the chances of leaving any sessions open).