Hi Janne, I've looked around the Apache site and unfortunately can find no ASF-wide coding conventions. It seems that ASF has never had a consistent set of conventions across its many projects, with some choosing an Avalon-like style for braces to avoid the K&R style (with all other syntax following the Sun standard). Other projects adopted other styles. There are many to choose from: Ambler, Lea, ESA (yes, the European Space Agency). Given no one "standard" is without flaws in someone's eyes this is not entirely surprising. While I don't like every bit of it, the one benefit of the Sun standard is that it is by far the most widely known and practiced, if we aren't too strict in interpretation.
I do note one thing clearly expressed on the JSPWikiCodingStandard page: no one seemed remotely in agreement about what constitutes "increased readability". It seems what one person thought readable others thought not so readable. A point you made was that once anyone had checked code into the JSPWiki project it was no longer the domain of the original programmer but became "common code". By the same token, code checked into the Apache JSPWiki project is now the domain of the ASF. Since historically it seems that each ASF team has chosen its own coding conventions, developers should therefore follow whatever conventions are chosen for the project by the project team, which I guess is the question before us. That is, unless someone from ASF has some guidance. Ichiro On Sat, Jul 20, 2013 at 6:47 PM, Janne Jalkanen <janne.jalka...@ecyrd.com>wrote: > > 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 > >> > >> > >
