Reasoning for style "B", aka K&R is here:
http://ecyrd.com/JSPWiki/wiki/JSPWikiCodingStandard
I do believe Sun made a mistake going for not aligning the braces - my
experience is that keeping braces on the same line significantly increases
code readability and works better in multi-line conditionals.
/Janne
On Jul 20, 2013, at 06:26 , Ichiro Furusato <ichiro.furus...@gmail.com>
wrote:
Hi,
I'd much prefer Style C as that's the "Sun standard", as you note used in
many Apache projects, and the default style of Eclipse's Format command,
which means that it's easy to auto-format an existing file to match the
Sun
standard. Style B is IMO a bit ridiculous -- it extends the logic of a
class vertically across so many lines that it becomes actually hard to
read
and the only benefit seems to be increasing the count of lines for those
who think that's a benefit. But rather than be ambiguous about it, I'd
suggest we simply reference the actual style of "Style B" in JSPWiki's
documentation:
Code Conventions for the Java Programming Language
http://www.oracle.com/technetwork/java/codeconv-138413.html (home
page)
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html(web
TOC)
http://www.oracle.com/technetwork/java/codeconventions-150003.pdf(PDF)
I'm not sure where Style B came from in the JSPWiki project, as the Sun
standard has been around for a very long time.
FWIW, all of the code for the Neocortext project (which uses JSPWiki as a
component) is roughly in the Sun standard (without being anal about it),
and I'd much prefer to not have to reformat the code for Style B in order
to submit any portions of it, such as plugins, etc.
So while I don't have a vote, +1 for Style C.
Ichiro
On Sat, Jul 20, 2013 at 9:35 AM, Glen Mazza <glen.ma...@gmail.com>
wrote:
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<
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<
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<
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<
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<
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
