[Python-Dev] PEP 7 clarification request: braces

Tres Seaver tseaver at palladion.com
Mon Jan 2 21:25:00 CET 2012

Hash: SHA1

On 01/02/2012 01:02 AM, Nick Coghlan wrote:
> On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial 
> <scott+python-dev at scottdial.com> wrote:
>> On 1/1/2012 11:44 PM, Nick Coghlan wrote:
>>> I think it's a recipe for future maintenance hassles when someone
>>> adds a second statement to one of the clauses but doesn't add the
>>> braces. (The only time I consider it reasonable to leave out the
>>> braces is for one liner if statements, where there's no else
>>> clause at all)
>> Could you explain how these two cases differ with regard to
>> maintenance?
> Sure: always including K&R style braces for compound statements (even 
> when they aren't technically necessary) means that indentation == 
> control flow, just like Python. Indent your additions correctly, and 
> the reader and compiler will agree on what they mean:
> if (cond) { statement; } else { statement; addition;  /* Reader and
> compiler agree this is part of the else clause */ }
> if (cond) statement; else statement; addition;  /* Uh-oh, should have
> added braces */
> I've been trying to convince Benjamin that there's a reason "always 
> include the braces" is accepted wisdom amongst many veteran C 
> programmers (with some allowing an exception for one-liners), but he 
> isn't believing me, and I'm not going to go through and edit every 
> single one of his commits to add them.

FWIW, +1 to mandating braces-always (even for one liners):  the future
maintenance burden isn't worth the trouble of the exception.  In the days
when I did C / C++ / Java coding as my main gig, braceless code was
routinely a bug magnet *for the team*.

- -- 
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Python-Dev mailing list