commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] Code review
Date Sat, 02 Oct 2010 20:17:55 GMT
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.


> On Sat, Oct 2, 2010 at 8:37 AM, Phil Steitz<>  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:
For additional commands, e-mail:

View raw message