In my relatively recent experience using my own code, several
thousand warnings (mostly due to the introduction of generics, now
fixed), resulted in 0 bugs found. But I try to write very clean code
to begin with.
Lloyd
On Sep 14, 2006, at 4:47 PM, Bill Shannon wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>