On Sat, Feb 26, 2011 at 2:14 PM, J.Pietschmann <j3322...@yahoo.de> wrote:

> On 26.02.2011 15:05, Glenn Adams wrote:
>
>>
>>> Establishing a zero-FindBugs policy at build level: absolutely not.
>>>
>>
>>
>> So you offer no rationale or reason for such an opinion? Or your only
>> reason
>> for this is that FindBugs is not perfect? Or because you find it too
>> troublesome to type "ant findbugs" and look at the results?
>>
>
>
> I haven't looked at your patch which fixed all the findbugs issues
> in FOP. Do you have the numbers of false positives and some
> estimates about the impact the real bugs would have had? If the
> numbers prove that findbugs systematically adds value, it might
> be worth changing policy.
>

I didn't actually fix the findbugs issues that predated my addition of the
findbugs-exclude file. Simon created a script that automatically added the
exclusions in order to zero out the findbugs error count. The hope (I would
not say expectation) was that as time permitted, folks would take the
opportunity to go back and review those pre-existing bugs and either make
fixes or add "blessed" exclusions, meaning adding a comment at least in the
exclusion file indicating the fact that review had occurred and a decision
had been taken to make the exclusion for a stated reason.

My experience so far with findbugs is that a reasonable percentage of the
issues it reports are indeed real or potential bugs, and that a relatively
small percentage (<10%) need to be excluded. Even in many of the latter
cases, the warning was suitable for consideration, e.g., warnings about
returning null or returning an empty array.

My expectation (not hope) was that once we eliminated the pre-existing
findbugs, that new commits would not add new issues. Otherwise, it is a
pointless exercise. My conclusion is that since findbugs does indeed
identify some real and potential bugs, that it is worth using and that a
zero findbugs policy should apply.

I find it hard to believe that professional programmers would think
differently.

Of course, no tool of this sort is perfect or even near so, but to simply
throw it out because it takes a few minutes to check and fix new issues
seems counterproductive to any stated goals of improving quality, not just
code quality but functional quality.

I noticed in a recent status report on FOP that it was felt worth mentioning
the work to improve quality. Someone apparently thought that worth pointing
out to others in Apache and elsewhere. Why we would not continue that policy
in using findbugs as well seems rather shocking to me.

In the numerous large software development projects I have led over the past
40 years, I have consistently used whatever tools were available, no matter
how imperfect, in the hope that they will identify a few useful bugs and
give some added confidence that a reasonable amount of due diligence was
applied in finding and fixing bugs.

However, saying all of the above, the largest barrier I see to fixing bugs
in FOP and improving its quality is the reticence of the clique of FOP
committers to accept new committers. Rather than bring in new blood and new
energy, folks seem to prefer to complain about the length of the bug list
and wring their hands and do nothing or little to improve the situation.

I have offered on numerous occasions to contribute actively to FOP, but I
cannot do so because I am not a committer, and having to go through
committers to make improvements is just too troublesome. My energy to
improve FOP has diminished considerably as a result.

G.

Reply via email to