FW: Switch statements again
maney at pobox.com
maney at pobox.com
Fri Jan 17 06:01:28 CET 2003
Carl Banks <imbosol at vt.edu> wrote:
> Mike Meyer wrote:
>> Carl Banks <imbosol at vt.edu> writes:
>>> switches are likely to make indentation a pain; it's not clear whether
>>> case tags should be indented or not. If they are, you have two
>>> indentation levels for the code inside. If they aren't, you've broken
>>> a fundamental property of indentation.
>> Why does not indenting the case tags break a fundamental property of
> Yes. All of the in statements look back to a single when. An elif
> looks only back to the previous if/elif. The in statements fall
I think this is spurious reasoning, although like you I agree with the
result "all if / elif / else at the same indent".
> "inside" the when statement. The elif falls "after" the previous
> if/elif. So, unindented ins is worse than unindented elifs: that
> which fall inside tags ought to be indented.
> However, the former is NOT any worse than try followed by a bunch of
> excepts. All the excepts look back to the same try. Conceptually,
> the excepts should be nested inside the try statement, but I (and
> everyone else) have been happily using them where they are.
> For that reason, I retract my statement.
I think the common reason that runs through all of these is that the
set of flow control keywords are properly seen as peers in a larger
structure. This was explained back in the dark ages of programming in
the "why chained else if is not indented every step" - back in those
days they hadn't yet discovered the "elif", you see. (the story that
Knuth had discovered elif but not described it becuase it was
considered too grotesque is plausible but probbaly apocryphal.)
I hesitate to dig this up, but this is also at the root of the
occasional strong desire for assignment on the fly. When what you need
to do is inherently an if / elif ... / else, it is annoying to have to
add spurious indentation in order to capture the value that is being
tested. I don't think I saw this so clearly when last we discussed
that issue, and I wanted to flush it before I lost sight of it again.
Anyway, I think this is the real rule that if/elif/else and
try/except/finally are obeying, and the one which IMO the switch
construct ought to follow as well. I have no strong opinion about the
choice of keywords, but I do hope we don't get a needless indentation
specified for this. Never mind that I've been writing 'case' at the
same level as 'switch' in C for longer than some of you have been
More information about the Python-list