Peter Williams wrote:
> Nandini Ektare wrote:
>
>> vince kraemer wrote:
>>
>>> like checkstyle, PMD or FindBugs as part of their "normal"
>>> development process?
>>>
>> Not sure how difficult it is but I wonder what does it take to
>> integrate these tools to existing configuration management scripts.
>> That way it automatically becomes part of normal development process...
>>
>> For e.g. During an attempt to checkin, detection of undesirable code
>> styles would trigger an action which could be
>> 1.displaying those to the developer
>> 2.as rigorous as checkin is not permitted
>> 3.or a warning mail to the desired alias post checkin
>
>
> IMO, far too much human interpretation is currently required of the
> results to eliminate false positives to allow any of these options to be
> practical at this time. This goes for FindBugs and PMD as I've used
> those two. Not sure about any others, but I would expect there as well.
I used to do this all the time for Solaris with cstyle and lint.
Getting to a "known good" state is a tremendous amount of work.
I kept a list of files that were known to be "clean". And for
each clean file I kept a list of "errors" that were known to be
safe to ignore. And where possible I modified the tools to allow
you to mark code as "clean" even though the tools would normally
complain. I believe FindBugs now has such support built-in.
Once you have these basic tools and mechanisms in place, you can
incrementally improve the code base, and you can ensure that it
stays "clean".
This really is worth the effort. If you've looked at any of the
FindBugs errors in our code, you'll understand how many real bugs
can be fixed this way.