incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Switching to different bracing style?
Date Sat, 20 Jul 2013 06:47:25 GMT

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.furusato@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.mazza@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
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message