@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.

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.