Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of glen.mazza@gmail.com
 designates 209.85.128.45 as permitted sender)
Message-ID: <51E9B12D.7070506@gmail.com>
Date: Fri, 19 Jul 2013 17:35:41 -0400
From: Glen Mazza <glen.mazza@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: jspwiki-dev@incubator.apache.org
Subject: Switching to different bracing style?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Team, the next Sonar complaint, and there's a significant 500 of them 
within JSPWiki, is that we're not using braces for single-line 
if/while/for loops.  I know for CXF braces are always required, and I 
suspect the majority of Apache projects today also disallow them, so the 
requirement is not unreasonable.  Fixing them is not the problem, what 
*is* the problem is our older-fashioned bracing system, i.e., instead of 
switching from this

Style A:

if (a > b)
    c = 10;
else if (d > e)
    f = 20;

to this (the bracing system JSPWiki presently uses):

Style B:

if (a > b)
{
    c = 10;
}
else if (d > e)
{
    f = 20;
}

I'd like to be doing this instead:

Style C:

if (a > b) {
    c = 10;
} else if (d > e) {
    f = 20;
}

I've checked five major open source projects -- Style C is all they use:

CXF - 
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/https/CertConstraintsFeature.java?revision=828758&view=markup

Camel - 
http://svn.apache.org/viewvc/camel/trunk/components/camel-atom/src/main/java/org/apache/camel/component/atom/AtomUtils.java?revision=1190212&view=markup

Tomcat - 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?revision=1189413&view=markup

Hadoop - 
http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-common/src/main/java/org/apache/hadoop/mapred/LocalDistributedCacheManager.java?revision=1466196&view=markup

Spring Framework: 
https://github.com/SpringSource/spring-framework/blob/master/spring-jdbc/src/main/java/org/springframework/jdbc/object/SqlFunction.java

Style B might be OK for projects that still allow Style A, but it makes 
the code too bloated once Style A is disallowed.  I don't think we'll be 
able to attract many committers sticking with Style B anymore.  
Basically, to avoid the busywork of converting Style B to Style C, we'll 
allow either in our source code but with the expectation that more and 
more code will be adopting Style C as time moves on, how does that 
sound?  (Or, do we want to continue with allowing Style A and Style 
B?--we're welcome to ignore Sonar on this.)

Regards,
Glen