incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <ichiro.furus...@gmail.com>
Subject Re: Switching to different bracing style?
Date Sat, 20 Jul 2013 03:26:51 GMT
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