Control System and source code quality

Sun and other pioneers have done a great job in defining some code conventions and best practices for java development. We all know that it would be easy to maintain our java codes, if we follow these conventions and best practices.

A basic rule in Control Systems is, if you want to control some process, you need the feedback signal, so that you can regulate it.

Say, you press the accelerator in your car. You would like to know at what speed you are driving, by looking at the speedometer. Then you would like to cruise often having a look at your speedometer to control your driving speed.

So, you need some device/instrument, here in this case a speedometer, to monitor/control some process.

(Needless to say that i'm an electronics and instrumentation graduate :)

Likewise, to control the quality of your code, you need some device/instrument to give you feedback/measurement of the quality of code, so that you can take actions based on it.

It's one thing to say to your team members, "Guys, the source code you write must follow the code conventions we have defined" and not enforcing a way to monitor it.

CheckStyle is one such tool to aid you in controlling the quality of your code. CheckStyle defines a set of "rules", which must be followed by the source code.

The rules are very simple to use and configure. You can configure them in a xml file. An easy way to start learning CheckStyle is to have a look at the sun_checks.xml file that comes along with the downloads.

Rules are defined as "modules". A simple rule regarding the brace position might look like this:

<module name="LeftCurly/>

This rule checks the position of the left curly bracket "{" in your java source. The default position is "end of line", which means:

public void myMethod() {
//do something...
}

But if your organization enforce some thing like this:

public void myMethod()
{
//do something...
}

you can configure CheckStyle to achieve that like this:

<module name="LeftCurly"/>
<property name="option" value="nl">
</module>

Or, if you want to enforce that all your methods must contain javadoc statements, it's very easy to achieve with a simple CheckStyle rule:

<module name="JavadocMethod"/>

To find unused, redundant imports in your java source code, just do this:

<module name="UnusedImports"/>
<module name="RedundantImport"/>

To make things much easy for the developers, CheckStyle offers many types of integration. You can either opt to run it from command line, integrate in your build process using ant/maven or directly integrate it with your IDE of choice.

We use both the IDE integration and the ant integration options.

If you are a NetBeans user, there are two nice plugins available:
1. CheckStyle4nb
2. CheckStyleBeans

The first one can be used to run CheckStyle rules on a java source file, package(s).
The second one integrates deeply into the IDE and marks the CheckStyle rules violations in the left side bar of NetBeans.

I use the first plugin a lot.

As the name implies, CheckStyle is more intended to check the "style", "formatting" of your java source code, though it contains some rules to find out some "bugs" in your code as well.
But finding "bugs" and "logical mistakes" in your source code is not which CheckStyle claims to do. PMD, FindBugs might be the right candidates for that job.

But I can assure you that CheckStyle will definitely make your java source code look better and easy to maintain. Be sure to check it out, if you haven't done so far.