it may be difficult to agree on a particular checkstyles policy, and I
really don't want to force creating or agreeing on such a policy, e.g., i
don't like to break lines for some arbitrary limit and i use nested blocks
and inline assignment, while others may not like that; however, i try to
respect the style of the author of a given file, so if the author uses a
line length limit, i will keep to it as well as other styles;

for me, it is more important to create and maintain a zero warning policy; i
don't care if the warnings are suppressed as long as an author gave them
legitimate review and decided they were acceptable;

both checkstyle and findbugs provides mechanisms for filtering the output to
suppress warnings, and that is what i would prefer using, to permit what i
call "blessed" warnings, etc.

the important thing is that some author/contributor has taken the effort to
review warnings and bless them if they are to be allowed or to remove their
underlying cause if not;

that is what i propose to do and to maintain;


On Tue, Aug 3, 2010 at 6:45 PM, Vincent Hennebert <>wrote:

> Hi Glenn,
> (Moving to general@ as maybe this is something we want to do at the XML
> Graphics project level. Please continue discussion there.)
> Thanks for bringing up this topic. I personally agree that
> a zero-warning policy would be A Good Thing. In theory newly committed
> code should have no Checkstyle warning, but I’m not sure that policy is
> thoroughly followed.
> Before enforcing such a policy it is necessary to come up with
> a Checkstyle file on which everyone agrees. The current one is not
> properly customized IMO. I started to create a new one from scratch
> a long time ago but never got round to finishing and testing it.
> Feel free to submit such a file. Once everyone is happy with it then you
> can start removing all the warnings on the current code if you feel like
> doing it. But doing it now would be a bit premature.
> I can’t really comment on findbugs, I must admit that I’ve never used it
> (me blushing with shame). This would probably also be a good thing to
> enforce its usage, but I suppose it also needs some customization.
> Thanks,
> Vincent
> Glenn Adams wrote:
> > Would anyone mind if I submit a patch that fixes all the outstanding
> > warnings, etc., reported during the build process and by checkstyles and
> > findbugs on the trunk? More importantly, if I do this, is it possible to
> > adhere to a zero tolerance policy on warnings for future commits?
> >
> > I find the 3000 or so warnings currently produced to be a rather
> significant
> > impediment to doing work on this code base, or at least, in preventing an
> > avalanche of new warnings upon future commits, given the trouble required
> to
> > determine the diffs between new warnings and old warnings. Perhaps this
> > isn't a problem for changes to one file, but for changes to a hundred
> files,
> > it is a major headache. Anyway, some of these 3000 are actually real,
> > lurking bugs.
> >
> > I'm willing to do the cleanup work if others will help maintain
> cleanliness
> > going forward.
> >
> > Regards,
> > Glenn
> >

Reply via email to