[Gluster-devel] if/else coding style :-)
Dan Lambright
dlambrig at redhat.com
Mon Oct 13 14:37:23 UTC 2014
+1 on choosing a single brace style [1] for the entire codebase.
[1]
http://en.wikipedia.org/wiki/Indent_style
----- Original Message -----
> From: "Shyam" <srangana at redhat.com>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>, gluster-devel at gluster.org
> Sent: Monday, October 13, 2014 10:13:38 AM
> Subject: Re: [Gluster-devel] if/else coding style :-)
>
> On 10/13/2014 10:08 AM, Pranith Kumar Karampuri wrote:
> >
> > On 10/13/2014 07:27 PM, Shyam wrote:
> >> On 10/13/2014 08:01 AM, Pranith Kumar Karampuri wrote:
> >>> hi,
> >>> Why are we moving away from this coding style?:
> >>> if (x) {
> >>> /*code*/
> >>> } else {
> >>> /* code */
> >>> }
> >>
> >> This patch (in master) introduces the same and explains why,
> >>
> >> commit 0a8371bdfdd88e662d09def717cc0b822feb64e8
> >> Author: Jeff Darcy <jdarcy at redhat.com>
> >> Date: Mon Sep 29 17:27:14 2014 -0400
> >>
> >> extras: reverse test for '}' vs. following 'else' placement
> >>
> >> The two-line form "}\nelse {" has been more common than the one-line
> >> form "} else {" in our code for years, and IMO for good reason (see
> >> the comment in the diff).
> > Will there be any objections to allow the previous way of writing this
> > if/else block? I just don't want to get any errors in 'check-formatting'
> > when I write the old way for this.
> > May be we can change it to warning?
>
> I am going to state my experience/expectation :)
>
> I actually got this _error_ when submitting a patch, and thought to
> myself "isn't the one-line form the right one?" then went to see why
> this check was in place and read the above. Going by the reason in the
> patch, I just adapted myself.
>
> Now, coming to _allowing_ both forms with a warning, my personal call is
> _no_, we should allow one form so that the code is readable and there is
> little to no confusion for others on which form to use. So I would say
> no to your proposal.
>
> Shyam
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
More information about the Gluster-devel
mailing list