Python paradigms

[Martijn Faassen]

Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
[if your function gets longer than a screenfull, it's time to start
thinking about splitting it up]

> It really is quite amusing to see these same old myths coming back
> every few decades :-)

You think splitting a function up is a myth? I find it helps 
me and my code. It becomes more readable and writeable. I'm genuinely
surprised by your assertion this is an 'old myth'.

> That particular dogma was very popular back in the late 1960s and
> early 1970s, when practical programmers pointed out that it was a
> virtually impossibility for a normal person to keep track of 50
> trivial functions in their head, but it was quite easy to look
> at 60 lines of sequential code.  That didn't get listened to
> then, either!

Of course if you go about randomly chopping up your function into
multiple ones, that's not going to improve matters. The idea is
to conceptually split your function into multiple smaller ones
that make more sense, are more easy to adapt, are coherent by 
themselves, and make the original big function more readable, as
by writing all the smaller functions you've hopefully also given
them names. It's called refactoring, of course. :)

My guidelines are:

If your function is long and complicated, too many concepts
and abstractions are mingling in the same place. Do a better job
of abstracting stuff, and you'll end up with shorter, clearer
functions.

If your function is long and repetitive, you're not being a lazy
enough programmer. Write some smaller functions that generate the
stuff, read it from a file or database, whatever.

If your function is long and simple..do these happen? They don't seem
to happen in my code. Then again, my "this is complicated" reflex is
triggered pretty quickly; I'm just not too smart. :)

Are you saying these guidelines are based on a myth?

[snip]
> My current infliction is a accounting file format, and the the
> function to check the input (you DO check your input, don't you?)
> needs to perform 100 tests in series.  Yes, I am inventing
> trivial functions, but it would be clearer to put more of the
> tests inline.

Why not split this up into a bunch of validation objects or 
something, and then check the input that way? And aren't at least
some of these tests similar enough to abstract into a function
(such as tests for maximum various lengths of strings). Of course
the accounting file format may be so baroque your function just
has to be baroque, but that sort of thing *ought* to be rare. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?