On 13Nov2014 19:04, Chris Angelico <ros...@gmail.com> wrote:
On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson <c...@zip.com.au> wrote:
Indeed. This aspect is a deal breaker for me; I'd never use it.
I make a point of putting the module's main function right up the top,
immediately after the imports and any "constants" (let's not dither over
that term). I _want_ the main function to in the reader's face when they
visit the module code. All the cogs come later.
And lots of my modules have "main" functions. Terribly useful.
Hmm, I go the other way. As much as possible, I prefer functions to
call what's above them, not what's below them - so the main function
would always be at the end of the file. [...]
My view is that if there's a main (i.e. the module implements a small app all
on its own, however tiny), then the main program logic should come first. The
details follow later.
For a pureply functional module (utility functions, classes built on them, etc)
I tend to go your way. But the main, if there is one, comes first.
The very top of the file
should have comments/docstrings etc, then imports, then pure utility
functions that don't call on anything else, then "guts" functions, and
finally routines that are called externally but never internally (like
main). That way, if you're wondering at what some name means, you go
to the top of the file and find the first occurrence; that'll usually
be its definition.
Sounds effective. I probably prefer my code (main aside, again) organised the
same way. Needless to say, I have a heap of modules that could do with a
cleanup along these lines.
Cheers,
Cameron Simpson <c...@zip.com.au>
If you make people think they're thinking, they'll love you; but if you
really make them think, they'll hate you. - Don Marquis
--
https://mail.python.org/mailman/listinfo/python-list
