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 >> >>
