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.)
Dear me, the 1960s called, they want their controversy over structured
programming back *wink*
Yes, you increase the length of the module by having function headers.
You also increase the length of the module by using meaningful names
instead of calling everything "a", "b", "c" etc. We're not playing code
golf, there's no reward for making unreadable code.
The dispatch mechanism is no more complicated than a series of if...elif
statements. In fact, you can replace an arbitrary number of "if x == y"
statements with a *single* lookup:
if x == 1:
return 27
elif x == 2:
return 14
elif x == 5:
return 7
else:
return -1
becomes the single line:
return {1: 27, 2: 14, 5: 7}.get(x, -1)
(although for more complicated examples, you would put the dict into its
own line, or even lines).
Dispatching isn't a panacea. You can't (easily) replace a series of
if...elif statements where the conditions being tested aren't equality
tests, e.g.:
if 0 <= x <= 1:
return 27
elif 1 < x < 1.5 or x == 2:
return 14
elif ...
is hard to turn into a dispatcher. But it's still a very useful technique
when it applies.
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.
That depends on the code. In particular, it depends on how coupled the
code is. Ideally, you should have loosely coupled code, not highly
coupled. If the code is loosely coupled, then there's no problem with
understanding it in isolation. If the code is highly coupled, then it is
hard to refactor it into a separate function, but that's a side-effect of
the original problem, namely the high degree of coupling.
As a general rule, if you need to know the context of the surrounding
code to understand a function, you have too much coupling.
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.
But how is that different from this?
if condition(x, 'attr'):
return process_attr(x)(ast)
elif condition(x, 'key'):
return process_key(x)(ast)
elif ...
Lexical duplication is one of the weakest code smells around, because it
is so prone to false negatives. You often can't avoid referring to the
same lexical element multiple times:
def sinc(x):
if x != 0:
return sin(x)/x
return 1
That's four references to x in a four line function. Is this a problem?
No, of course not.
