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

[Steven D'Aprano]

On Wed, 18 Nov 2009 17:14:27 -0800, Steve Howell wrote:

> In my rewritten code, here is the smell:
> 
>     dispatches = {
>             'dict': _dict,
>             'list': _list,
>             'attr': _attr,
>             'key': _key,
>             'as': _as,
>             'call': _call,
>             'recurse': _recurse,
>             }
>     if kind in dispatches:
>         return dispatches[kind](ast)
>     else:
>         raise Exception('unknown kind!')
> 
> 
> There is nothing wrong with the code taken out of context, but one of
> the first things that lexical duplication should alert you to is the
> fact that you are creating code that is brittle to extension.

Really? It is very simple to extend it by adding another key:item to the 
dict.


> In my
> example, the reference to _dict is 36 lines of code away from its
> implementation, which forces indirection on the reader.

It gets worse -- the reference to the in operator is in a completely 
different module to the implementation of the in operator, which may be 
in a completely different language! (C in this case.)

I'm being sarcastic, of course, but I do have a serious point. I'm not 
impressed by complaints that the definition of the function is oh-so-very-
far-away from where you use it. Well duh, that's one of the reasons we 
have functions, so they can be used anywhere, not just where they're 
defined.

If a function *only* makes sense immediately where you use it, then the 
level of coupling is too great and you should either reduce the coupling 
or bite the bullet and live with all the hassles of inline code. (Code 
duplication, difficulty in testing, etc.)

Of course it would be convenient if, having noticed the reference to 
(say) function _recurse, you could see its definition without needing to 
do more than just glance up a line or two. But you should rarely need to 
care about the implementation -- that's another point of functions. You 
should be able to treat _recurse as a black box, just as you use the 
built-in function len as a black box without needing to see its 
implementation every time you use it.



-- 
Steven