Check Style

CheckStyle is a development tool to help programmers write JavaLanguage code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard. It's OpenSource and can be found at http://checkstyle.sourceforge.net/.

Use it with ApacheAnt in your build scripts, it's a GoodThing to decide in your TaskCompleteDefinition that CheckStyle should produce no error on the code. -- PeterAxelsson

Somehow I can't imagine this being a good thing. Does anyone have any experience with this on a substantial project?

Would you care to elaborate why you don't think it's a good idea to have a tool to check for adherence to CodingConventions?

I don't think the problem is with the enforcement of coding conventions. The problem occurs when code doesn't build unless it passes style checks. If your coding conventions haven't been very carefully designed then you end up mangling your code just to get it to build. The 80 character line limit, for example, is the kind of thing that can really reduce the readability of code.

Using a tool like CheckStyle works best when it's a separate task used in CodeReviews? and as part of refactoring rather than an essential part of the build process.

Ah, maybe I was a bit unclear. The way I use it is as a target in my ApacheAnt script. It's not invoked everytime you compile, I run it on my code prior to I check-in the code to the version control system in order to comply to our TaskCompleteDefinition which says that checked-in code should follow our CodingConventions. Note also that CheckStyle is a configurable tool, you don't have to have 80 characters as a line limit (even though I personally find 80 to be sufficient).

The 80 character line limit, for example, is the kind of thing that can really reduce the readability of code.

Actually, I disagree here. I use an editor with just 80 chars per line, and I can't imagine that it's more readable if my editor breaks the line somewhere.

The problems tend to occur when you start having to expend more and more effort working out how to break long lines up so they'll be less than 80 characters. Having said that I really like CheckStyle. It's great for identifying things like redundant imports left over from previous refactorings.

I wrote something similar to CheckStyle, for internal consupmtion only :). It's a bit stronger as well - checks not just style but analyzes the code for stuff like unused variables, potential NPEs etc.. I've solved the problem you're talking about by classifying the messages (waring, error, critical) and an ability to set the task when it should fail the build . For example, you could say that you can have any number of warings, no more than 100 errors, no criticals. Of course, you can set the classification of any particular check and tell the checker to ignore a set of source files (for any or all rules). Configurability is everything :).

Well if you really want something closer to StaticAnalysis? then JavaLint is your friend. CheckStyle has also recently (in the last year or so) gained the ability to enforce rules like method length and file length. So you can get automatic enforcement of ShortMethods.

The solution I prefer is automatic code formatting on repository check in. Each developed can use their own auto formatter to set the style they prefer, but all code is stored in a standard style. I wouldn't hold up a build because someone's lines were too long, especially when I can automate formatting.

I find it interesting that people tend to focus on how it can be configured to check for line lengths and other syntax style checkss. When I come across a project with lots of errors like this, I use a tool like Jalopy to reformat the code.

But the biggest benefit of a tool like Checkstyle is enforcing things that cannot be fixed by a code formatter. For example:

Checking that the Javadoc exists and matches the code
Design rules, like ensuring an API is engineered for extension via hooks (a new check in Checkstyle 3.1)
Standard coding idioms, like required an equals() and hashcode() method
Naming rules
etc

I use CheckStyle in code reviews. Often, when I put a relatively big chunk (say, 10 KLOC) of code through CheckStyle, all I get is several hundred complaints about formatting and Javadoc, and maybe ten or twenty other warnings (perhaps, more interesting).

My response is to have two CheckStyle configurations. One with all checks on, the other with formatting and Javadoc checks off. So, we run the first one, probably put a note like "Code under review does not comply with coding standard requirements on formatting and Javadoc comments", then run the second one and start paying attention to what it says. Subsequent naked eye walkthrough catches an order of magnitude more errors than CheckStyle warns about, but some CheckStyle warnigs are easily overlooked by naked eye, and it doesn't cost much to run it. So, why not?

By the way, JavaLint looks at compiled classes, not source files. In my experience the kind of warnings it produces is almost orthogonal to CheckStyle. For this reason, I use both, together.

-- AlexeyVerkhovsky

Checkstyle errors are not as serious as unit test failures so they don't need to fail the build. We post the results to a web site and peer pressure keeps the number of violations low. It is important to restrict the checks to things that you care about and are able to justify. For instance we don't enforce 80 character lines but we are stringent about variable names.

CategoryJava CategoryLint