Python paradigms

[Nick Maclaren]

In article <8ctkm5$bko$2 at newshost.accu.uu.nl>,
Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>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'.

The myth is that splitting functions up necessarily improves clarity.
Sometimes it does; sometimes it doesn't.

>> 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. :)

The dogma is that there is a maximum size of function that should
ever be written, and that complex functions necessarily split up
cleanly into smaller sections.  Sometimes they do; sometimes they
don't.  I have seen codes where the median size of functions was
below 5 lines, and you had to keep the specification of over 50 in
your head just to read the simplest function!

>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.

Sometimes.  I have very often done that and backed off, because the
complex function was clearer.  Another good rule is, if auxiliary
functions need to access more arguments and artificial global
variables than they have lines of code, consider whether they would
be better written inline.

>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 the repetitiveness is not quite regular enough to make that easy,
you are making unnecessary work for yourself.  Sometimes that is the
right solution; sometimes it isn't.

>Are you saying these guidelines are based on a myth?

No - the myth is that they invariably improve things.  Life is not
that simple.

>> 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. :)

That is, of course, what I am doing.  But designing in enough
commonality takes a lot longer (and is more complex) than simply
repeating the very simple tests.  After all, it gains you nothing
by calling an auxiliary that then has a massive switch statement
with special code for each of its calls - and some people do write
code like that!

In this particular case, there are 50-60 entries, which need
40-50 separate test conditions.  By thinking, I can common up
quite a lot of that code, but there is some which is not amenable
to that.


If you remember, I asked whether there were any equivalent to a
couple of very common paradigms, that have been used to clarify
code for over 30 years.  The answer appears to be "no", so I have
to use somewhat less satisfactory ones.  This is not a major
problem - been there, done that, in dozens of languages.

What isn't acceptable, however, is putting up with people saying
that it is heretical to admit that such requirements exist!  Fads
are one thing, but dogma is harmful.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679