Article Series: “Automated code reviews with Checkstyle” on JavaWorld
Posted by ShriKant Vashishtha in the wee hours: November 26th, 2008
Today JavaWorld published my article series "Automated code reviews with Checkstyle" in 2 parts.
Part 1:
Automated code reviews with Checkstyle, Part 1
Part 2:
Automated code reviews with Checkstyle, Part 2
This article series attempts to bridge the gap of code review with applying automated Checkstyle checks in a complete and proactive way. First goal is to make the task of custom Checkstyle rules creation so simple so that any enterprise IT team could create new custom rules suiting to their project (IT standards) needs.
Second goal is to apply these rules in PROCTIVE fashion. Instead of waiting the build to fail or waiting for rule violation reports and working on them in a reactive way, the idea is to apply these checks proactively with Checkstyle Eclipse plugin or applying them at SVN level itself. Irrespective of which IDE you are using, if your code contains some of the high severity violations, you will not be able to commit the code in SVN. You will see the same kind errors and location on SVN console as you see with Eclipse plugin. This is achieved using SVN pre-commit hooks.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)
Excellent articles. The concept of proactive code reviews before the code hits the repository is very good to know.
Personally I think that checkstyle introduces a lot of noise. There are a few useful metrics like method complexity, but there are other tools for that as well.
And I have seen too many projects that focus on the very low level style issues (brackets, whitespace, etc), but where there are big differences in design. The problem is that static analysis tools to detect these problems, are much harder to find. So the human factor is still invaluable.
You always have an option of configuring the checkstyle ruleset to take away what you consider as noise, this includes whitespaces and other formatting checks. In my view some of the things like RFC, DIT, NOC, Coupling are things which you should be able to check with a tool to see if your design is good. Of course you would not be able to take out the human factor completely but automation helps, metrics as a tool would help in this case or CAP for that matter. Also various other SCA metrics like size, CC, Npath, boolean expression complexity etc would help you keep your code clean, understandable, testable, reliable etc etc
Thanks Vikas for the appreciation.
@Peter. If you read the articles in detail, I focus on using Checkstyle custom checks to avoid severe design issues. I also hate using such tools for trivial stuff (brackets, whitespace stuff). But the same tool can be used for writing some cool checks. For instance, in a project where it is completely a NO-NO to write any singleton if they are using Spring, a custom Checkstyle check does the trick. You will not be able to compile that code. Similarly the example I mentioned in the article, you can avoid accessing a method on potentially NULL object. It’s also useful for code-analysis reasons for audit/performance tuning assignments. At the end of it, it’s always upto the project team to abuse or use a tool. However in my view Checkstyle custom checks and its proactive implementation is something a lot of projects (especially big or Waterfall model based or with a lot of inexperienced deevelopers) look for.