What matters is the amount of tool usage. In a highly automated environment where daily builds are happening more than once every day, monitoring commits and generating reports, it makes a lot of sense to integrate these tools. Having this in place is just as good as 50% work done.

I think enforcing the tool usage (by making it a part of commit) is the issue. Instead, senior members in the team could take the responsibility of doing smart code reviews. This is as good as using the tool itself (might be better at times). However, the advantages of unit testing tool or code metrics tool are too good to be ignored.

I recently inherited a project that was big pile of stinking crap and all my static code analysis tools confirmed this (though technically I didn’t need those to confirm this). When maintaining big stinking piles of code, analysis tools, test tools, etc. are your friend.

Step 1: fix all of those findbugs issues. You know dereferencing null values, redundant null checks, misguided use of the synchronized keyword, etc. Step 2, use code coverage tools to figure out what code is not being tested. Step 3: fix this, ruthlessly deleting dead code in the process (if it has no test and nobody seems to use it: delete and ask questions later). Step 4: Refactor, the hell out of the project. Breaking things is going to happen from time to time. But then once you fix it, your code will be better. Step 5 work on the code until you have 0 warnings with the code analysis tools running on each save in eclipse (no expert would turn those off). This probably requires some decision taking on which rules to keep and which not. Step 6: turn on code cleaning on save in eclipse. Really, this saves so much time and arguing. Our eclipse config comes straight from maven so all team members use it. Hooks up the code analysis tools as well. Great stuff.

Indeed no replacement for code reviews, unit, integration, and manual end-to-end testing. But then nobody claims this and you shouldn’t rely on those processes either to find stupid rule violations and instead focus more on correctness & design of the code.

Out of the box, PMD can be overly verbose. It is easy to let it run more rules than is necessary. One of the “expert” developers should set up the rulesets that will be enforced. Even after that, the rules should still be considered guidelines. As the article mentioned, there are often good reasons for a particular code construct that may violate a PMD rule. PMD supports both annotations and special comments that allow the developer to indicate to PMD (and to other developers) that they are ignoring the PMD rule on purpose. A good developer will also add a comment indicating why they are ignoring the rule. It is also possible to suppress PMD warnings for an entire class, so in the example from the article, the developer has a better choice: make the fix for the NPE, then suppress PMD warnings for the class. This should also serve as an indication that the class needs to be revisitied, but gives the developer a way to make a critical fix on a tight deadline without having to “fix” a bunch of legacy code that has worked fine for years.