Python indentation
David Bolen
db3l at fitlinxx.com
Wed Jul 7 19:50:03 EDT 2004
Steve Lamb <grey at despair.dmiyu.org> writes:
> 8 lines. But that's because I never understood why anyone would
> willingly use the '} else {' construct since the else is ovten
> obscured. Keyword opens the block, } ends the block, never put a
> block open and close on the same line.
Oh, I thought I wouldn't contribute to this thread, but what the hey...
I certainly willingly use the "} else {" construct - probably to me
because it stands out quite well and doesn't add additional noise
along the left edge (the } and else on separate lines feels jarring to
my eyes). There's plenty of density in the "} else {" (as opposed to
a simple closing brace) to draw my eye.
Clearly it's an "in the eye of the beholder" thing. I will admit to
being a K&R "one true brace style" guy. Maybe from having learned C
with K&R, but possibly a subconcious effort to minimize my brace
impact (minimize wasted empty brace only lines and impact on the
visual blocks I was creating) on what was otherwise an indentation
based block format I was trying to express. Little did I know I
really just wanted Python :-)
Interestingly, I never even really considered the else and next
opening brace ("else {") on its own line as an option - the folks that
I've seen use else starting on its own line also tend to be those that
prefer the Allman/BSD style of braces, in which case else would be
alone on the line with the closing and opening braces on their own
lines above and below it. I don't mind BSD style, but it does eat up
a lot of extra lines that only have braces on them, which cuts down on
the density of code you can view easily on a single screen.
Then again, I also see and feel similarity between my formatting of C
in:
if (stuff) {
do something
} else {
do something else
}
and my Python:
if stuff:
do something
else:
do something else
is in terms of indentation and line position of portions of the flow
control. The only brace in the C code that unnecessarily adds lines
is the final closing one. Of course I'm sure the same argument could
be worded about the other popular formats. To each his own :-)
-- David
More information about the Python-list
mailing list