I'm not trying to say it's not worth the effort. Engineering management
has to decide what level of resources should be applied to this and when.
The number of reports currently flagged mean that putting any sort of
automated system in place would grind development to a halt and force
immediate resolution of a very large number of problems (many of which
are not really problems or not worth fixing right now.)
That said, this evening Vince and I had an opportunity to examine many
of the reports on Glassfish flagged under "Correctness". Most of the
problems were genuine bugs in the code, some benign, some not. Some are
easily fixed, some less so. For example, we found some threading bugs
that correctly identified potential bugs. But who's to say that fixing
them wouldn't cause a deadlock? How good are our tests for this sort of
thing?
I would recommend cleaning the most serious deficiencies up as
expediently as the schedule allows and checking the more benign problems
on a less aggressive schedule with a long term goal of having the code
be as clean as reasonably possible.
-Peter
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
>