On 10/2/10 3:25 PM, Ted Dunning wrote:
Another option is to have a small community of activists who are willing to
comb the code and improve it without requiring everybody to catch all these
issues.
If what you mean by this is that we don't expect committers to fix
checkstyle / findbugs errors before committing code, that is a
logical option but not how we have worked in [math] up to now. As
the one who usually ends up having to RM, I am -1 on moving to this
approach. It is *much better* to keep the code clean when we check
it in, using the reports integrated into the build to flag issues
that we need to fix. If what you mean is that we should welcome
patches to make improvements beyond what is picked up by the static
analyzers in the build, I agree with that, as long as these patches
actually improve the code.
Phil
On Sat, Oct 2, 2010 at 8:37 AM, Phil Steitz<phil.ste...@gmail.com> wrote:
From my perspective, checkstyle.xml effectively represents our coding style
rules. I am fine with people making cosmetic changes that go beyond what is
specified in those checks, but I am -1 on requiring access to or specifying
usage of any specific IDE to ensure compliance with [math] coding standards.
I am also fine with adding other static code analysis plugins such as
findbugs to point out potential bugs, as long as we maintain the associated
config files and uniformly either fix or manage exceptions. Here again,
tools need to be freely available and IDE-independent if we expect the
community to use them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
