This post originated from an RSS feed registered with Java Buzz
by Oliver Burn.
Original Post: Checkstyle, a victim of its early success
Feed Title: Oliver's Blog
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Contains the rantings of me. The thoughts are all personal and do not reflect at all on the companies I work for. (mumble: damn lawyers!)
When I started work on the open-source version of Checkstyle in 2000, I planned to make it a tool to find as many problems as possible before code reviews (and you do code reviews, don't you? ;). And sometimes it may even be used as a substitue for code reviews - on the theory that something is better than nothing.
I tend to follow the rule of going after low-hanging fruit, so the initial emphasis went into checking the easy stuff like the use of braces and the proper use of whitespace. IMHO, probably the best early stuff was the support for checking Javadoc comments and naming conventions.
Unfortunately to this day most people think this is all that Checkstyle does. The other day a friend of mine referred to the Checkstyle 2.4 release as being the ""Gold Release", which is all people ever use. But this is far from the truth, as Checkstyle has evolved a long way since then.
One of the major problems with the early version of Checkstyle was the architecture. It was not easy for other people to develop their own checks, and plug them into Checkstyle. This meant that new checks had to be developed mainly by myself and Lars. So in the long-term it was not good approach.
When PMD appeared on the scene, it was clear that a cleaner architecture could be achieved. I remember discussing with Lars whether we should effectively stop work on Checkstyle and port our checks into PMD. In the end we decided not to because one of the advantages of Checkstyle over PMD is that is much faster. So it became a challenge to come up with an architecture for Checkstyle that would support plug-ins as easily as PMD, but not suffer the performance costs. In the end we jointly came up with an optimised visitor pattern which formed the core of Checkstyle 3.
The benefits of this change can be clearly seen now. The number of committers for the project has grown from 2 to 4. The number of checks available has grown significantly to include checks for common coding problems, class design techniques and other miscellaneous checks. The other day we received a contribution containing over 20 checks that are going to be incorporated into the main distribution. There is even be the suggestion to use the core of Checkstyle to support other languages. This is entirely possible given the fact that a lot of the Checkstyle architecture is language independent.
But after reading this blog from Alan I was left thinking, but if only he knew how easy it was to write a Check for this kind of stuff. The irony is that I have had drinks with Alan, and I should add, it was a good night.
I am not sure what is the best way to go about communicating how Checkstyle has changed since the old 2.4 release. If you have a good idea, please let me know.
Previous Topic
