No Broken Windows...
is one of the principles that the Eclipse folks mentioned in the JavaOne
IBM keynote (Thursday morning). The name of the principle is by analogy
to what happens to an abandoned house that has broken windows... an
accpetance that things are broken and a downhill deteriorating effect.
So, the Eclipse guys (say they) make a point of trying to clean things
up all the time. This seems a very good principle and I think we should
follow up.
Starting with the "Correctness" bugs seems good. Focusing on one file
at a time seems good. Eventually we want a house that we can all be
proud to show our friends and family.
And yes, Bill, I owe a summary of the Eclipse prezo.
- eduard/o
Peter Williams wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>