What are the best practices for implementing Java Checkstyle validation checks?
I am new to static code analysis tools for Java like CheckStyle. I downloaded the Checkstyle package and saw 2 sets of checks:
- checkstyle_checks.xml
- sun_checks.xml .
I compared these and geosoft_checks.xml to a master list of all available in the checkstyle ... essentially a 4-table outer join to see which checks were included in most of the three sources.
checks | source
----------- | -------------------------------------- ------------ ------
134 ....... | All available
75 ......... | checkstyle_checks.xml (plus the SuppressionFilter parameter pointing to suppressions.xml)
63 ......... | sun_checks.xml
73 ......... | geosoft_chekcs.xml (after removing 4 that don't work in checkstyle 5.7)
- DoubleCheckedLocking
- PackageHtml
- TabCharacter
- GenericIllegalRegexp
I just did an analysis on sun_checks and geosoft_checks to determine which ones can be safely removed based on actual results in the codebase (of course someone might come along and break one of the many checks not included in either)
Are there any recent guidelines for which reviews should be included that won't unnecessarily frustrate the development team? Do people have an extended checkstyle with helpful checks that have been contributed back to the open source community?
source to share
This is a great question, and one that takes much longer to answer than a simple SO post. Let me try again.
First, there is no universally accepted general guideline to help you. Anyone who comes to you with such a guide is actually only selling their own stuff. Therefore, I firmly believe that there is nothing you can do, activate and do. It's sad, but here we are.
Sun_checks are mostly historical and focused on formatting and naming. They are probably still the best place to start if you have nothing else. Checkstyle_checks is a Checkstyle command used to check its own code. I am not aware of geosoft_checks, which appears to be a well-documented form of local recommendation. There is also the Google Java Style which has become quite popular, but afaik doesn't have a corresponding Checkstyle ruleset yet.
Checkstyle is a tool that can do much more than just check the style of Java code. You have already shown that there are almost twice as many checks available that are used by rulesets. My own ruleset uses 99 checks, but it's very tailored to the solution we're building.
However, I believe that if you are serious about analyzing static code, you will have to go through the list of all the available checks and put together your own set of rules. And you will add this project to it to cover more and more cases where you have identified the potential for errors in the solution you are building. Fine-tuning and adding to the Checkstyle profile will be an ongoing task (say an hour a week).
If you want to avoid "unnecessary frustration of the development team," the most important aspect is that your rules are clearly, well documented and consistent. Also, integrate Checkstyle with your nightly build and / or version control system.
The most outstanding Checkstyle extensions are SevNTU Checkstyle and Checkstyle Addons . The lead guy from SevNTU Checkstyle is also the main contributor to Checkstyle today, so maybe they'll merge in the future.
source to share