+1 to existing Linux kernel style. Moreover, its a style which is used
heavily in existing code base. I don't see any advantage in changing the
style now.

On Mon, Oct 13, 2014 at 9:12 PM, Kaleb S. KEITHLEY <kkeit...@redhat.com>
wrote:

> <top post>
>
> ISTR we agreed to use Linux kernel style!
>
> Which is
>
>    if (foo) {
>        /* ... */
>    } else {
>        /* ... */
>    }
>
> I don't recall any discussion on -devel about changing this.
>
> </top post>
>
>
> On 10/13/2014 11:05 AM, Pranith Kumar Karampuri wrote:
>
>>
>> On 10/13/2014 07:43 PM, Shyam wrote:
>>
>>> 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 <jda...@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.
>>>
>> Hmm... okay (It is still not an emphatic yes). But it is a waste of time
>> to talk more about this.
>>
>> Jeff/Vijay,
>>        I urge you guys to notify others before making basic style
>> changes like this.
>>
>> Pranith
>>
>>>
>>> Shyam
>>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
>
> --
>
> Kaleb
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

Reply via email to