> He keeps leaving them out, I occasionally tell him they should always > be included (most recently this came up when we gave conflicting > advice to a patch contributor). He says what he's doing is OK, because > he doesn't consider the example in PEP 7 as explicitly disallowing it, > 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)
While this appears to be settled, I'd like to add that I sided with Benjamin here all along. With Python, I accepted a style of "minimal punctuation". Examples of extra punctuation are: - parens around expression in Python's if (and while): if (x < 10): foo () - parens around return expression (C and Python) return(*p); - braces around single-statement blocks in C In all these cases, punctuation can be left out without changing the meaning of the program. I personally think that a policy requiring braces would be (mildly) harmful, as it decreases readability of the code. When I read code, I read every character: not just the identifiers, but also every punctuation character. If there is extra punctuation, I stop and wonder what the motivation for the punctuation is - is there any hidden meaning that required the author to put the punctuation? There is a single case where I can accept extra punctuation in C: to make the operator precedence explicit. Many people (including myself) don't know how a | b << *c * *d would group, so I readily accept extra parens as a clarification. Wrt. braces, I don't share the concern that there is a risk of somebody being confused when adding a second statement to a braceless block. An actual risk is stuff like if (cond) MACRO(argument); when MACRO expands to multiple statements. However, we should accept that this is a bug in MACRO (which should have used the do-while(0)-idiom), not in the application of the macro. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com