Language mavens: Is there a programming with "if then else ENDIF" syntax?

[Steve Howell]

On Nov 18, 1:32 am, Chris Rebert <c... at rebertia.com> wrote:
> On Wed, Nov 18, 2009 at 1:15 AM, Steve Howell <showel... at yahoo.com> wrote:
> > On the topic of "switch" statements and even-more-concise-then-we-have-
> > already if/elif/else/end constructs, I have to say that Python does
> > occasionally force you to write code like the code below.  Maybe
> > "force" is too strong a word, but Python lends itself to if/elif
> > blocks like below, which get the job done just fine, but which are not
> > syntactically pretty, due to the "(el){0,1}if kind ==" duplication.
> > There are often cases where if/elif statements are just a smell that
> > you do not know how to do dictionary lookups, but if you converted the
> > below code to use dictionary lookups, you would complicate the code
> > almost as much as you abstracted the code, if not more, unless I am
> > just being very naive.
>
> I'm gonna have to disagree and say using the dictionary dispatch
> technique would clean it up a good bit.
> Yes, it would entail creating several functions, but those functions
> could then be documented (vs. the currently opaque code blocks); and
> due to their separation and smaller length, they would be easier to
> understand and test than the given code.
> Additionally, the sheer length of the given code segment probably
> constitutes a code smell in and of itself for the function containing
> that code.
>

If you introduce seven tiny little methods, aren't you increasing the
length of the module by seven lines and introducing more complexity
with the dispatch mechanism? (Actually, it's 14 lines more if you put
a line of whitespace between your methods, and then you are also
blurring an important cue that each of the seven code blocks all
perform within the same context.)

I do agree with your point that separate methods lead to easier unit
testing.

I'm a little more skeptical about the documentation/understanding
argument, since code is often best understood within the context of
surrounding code.  I am also a bit skeptical of any coding technique
that leads to lexical duplication like {'attr': process_attr, 'key':
process_key, 'call': process_call}(ast); that is just replacing one
smell with another.  Of course, you could do something like __modules__
[kind](ast) too, but that gets a bit overly abstract for a simple
dispatch.

Having said all that, I'm gonna take your suggestion...thanks for the
response!