On Sat, Feb 26, 2011 at 2:14 PM, J.Pietschmann <[email protected]> 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.
