I've wondered about that myself.  I tried working with the Trunk and got
countless warnings.  They included dead code, deprecated methods, and
unused assigned variables among other things.  To sift through you could
go into project specific compile options in Eclipse and tell it to
ignore them if you have the project created as source.  There may be an
option to ignore on the ant build that's not as obvious but clean code
would be appreciated, even as much as I appreciate the dirty code if the
warnings don't crash anything and it got some useful features
implemented faster.  I would hope there's less urgency to implement now
that the project has passed the 1.0 mark and code can be kept clean.


From: Glenn Adams [mailto:gl...@skynav.com] 
Sent: Tuesday, August 03, 2010 4:27 AM
To: FOP Developers
Subject: fixing and maintaining zero reported warnings policy?

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.


Reply via email to