[Python-Dev] Update PEP 7 to require curly braces in C

[Nick Coghlan]

On 19 January 2016 at 14:40, Alexander Walters <tritium-list at sdamon.com> wrote:
>
>
> On 1/18/2016 23:27, Greg Ewing wrote:
>>
>> Brett Cannon wrote:
>>>
>>> For me, I don't see how::
>>>
>>>   if (x != 10)
>>>     return NULL;
>>>   do_some_more();
>>>
>>> is any clearer or more readable than::
>>>
>>>   if (x != 10) {
>>>     return NULL;
>>>   }
>>>   do_some_more();
>>
>>
>> Maybe not for that piece of code on its own, but the version
>> with braces takes up one more line. Put a few of those together,
>> and you can't fit as much code on the screen. If it makes the
>> difference between being able to see e.g. the whole of a loop
>> at once vs. having to scroll up and down, it could make the
>> code as a whole harder to read.
>>
> When someone trying to make this argument in #python for Python code... the
> response is newlines are free.  Almost this entire thread has me confused -
> the arguments against are kind of hypocritical; You are developing a
> language with a built in design ethic, and ignoring those ethics while
> building the implementation itself.

There are two conflicting code aesthetics at work here, and the
relevant one for the folks that prefer to avoid braces in C where they
can is:

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

So if we bring *Python* into the comparison, we can see it splits the
difference between the two C variants by omitting the closing brace
and replacing the opening brace with ":":

  x = do_something()
  if (x != 10):
    return None
  do_some_more()

The additional "cost" of mandatory braces in C is thus more lines
containing only a single "}", while the benefit is simply not having
to think about the braceless variant as a possible alternative
spelling.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia