Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #4580 > unrolled thread

vertical ordering of functions

Back to article view | Back to comp.lang.python

Contents

  vertical ordering of functions Jabba Laci <jabba.laci@gmail.com> - 2011-05-03 18:08 -0400
    Re: vertical ordering of functions Ben Finney <ben+python@benfinney.id.au> - 2011-05-04 09:58 +1000
      Re: vertical ordering of functions John Bokma <john@castleamber.com> - 2011-05-03 19:44 -0500
    Re: vertical ordering of functions Roy Smith <roy@panix.com> - 2011-05-03 20:27 -0400
    Re: vertical ordering of functions Grant Edwards <invalid@invalid.invalid> - 2011-05-04 01:09 +0000
    Re: vertical ordering of functions John Roth <johnroth1@gmail.com> - 2011-05-04 04:14 -0700
    Re: vertical ordering of functions Hans Georg Schaathun <hg@schaathun.net> - 2011-05-10 19:31 +0100

#4580 — vertical ordering of functions

Hi,

I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
5 he says that a function that is called should be below a function
that does the calling. This creates a nice flow down from top to
bottom.
However, when I write a Python script I do just the opposite. I start
with the lines

if __name__ == "__main__":
    main()

Then I add main() above, which is a control function that contains
some function calls that decompose the problem into subproblems. Then
I add these functions above, etc.

Is there a convention for this? Should main() be at the top and called
function below?

Thanks,

Laszlo

[toc] | [next] | [standalone]

#4588

Jabba Laci <jabba.laci@gmail.com> writes:

> Is there a convention for this? Should main() be at the top and called
> function below?

No, it's Python convention for both of those to be at the end of the
module.

I follow the convention described by Guido van Rossum in
<URL:http://www.artima.com/weblogs/viewpost.jsp?thread=4829>.

Essentially, the mainline code is all in a top-level function, which
accepts command-line arguments in its ‘argv’ parameter, catches any
‘SystemExit’ exception, and returns the exit code for the program.

The ‘if __name__ == "__main__"’ section does nothing but call that
function, passing the ‘sys.argv’ value, then exit with the return value.

This makes the whole behaviour of the program available for calling as a
function, while the program works as expected when invoked as a program.

Commonly I will name the function ‘__main__’, but this is an artefact of
my previously-held vain hope that this idiom would become special to
Python and called automatically without the ‘if __name__ …’ hack. Guido,
and most others I've seen use this idiom, simply name the function
‘main’.

-- 
 \       “An idea isn't responsible for the people who believe in it.” |
  `\                                      —Donald Robert Perry Marquis |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#4591

Ben Finney <ben+python@benfinney.id.au> writes:

> Jabba Laci <jabba.laci@gmail.com> writes:
>
>> Is there a convention for this? Should main() be at the top and called
>> function below?
>
> No, it's Python convention for both of those to be at the end of the
> module.
>
> I follow the convention described by Guido van Rossum in
> <URL:http://www.artima.com/weblogs/viewpost.jsp?thread=4829>.

Thanks Ben, very useful link.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/    Facebook: http://www.facebook.com/j.j.j.bokma
    Freelance Perl & Python Development: http://castleamber.com/

[toc] | [prev] | [next] | [standalone]

#4590

In article <mailman.1127.1304460530.9059.python-list@python.org>,
 Jabba Laci <jabba.laci@gmail.com> wrote:

> I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
> 5 he says that a function that is called should be below a function
> that does the calling. This creates a nice flow down from top to
> bottom.

There may have been some logic to this when people read programs on 
stacks of green-bar or rolls of teletype paper.  These days, we have 
better tools.

When I'm reading some code and see a function call I want to explore, I 
search for the function name in my text editor.  People who use an IDE 
can probably just click on the function name.  In either case, the tool 
takes me where I need to go.  I'm generally completely unaware whether 
it's taken be forward or backward in the file.

[toc] | [prev] | [next] | [standalone]

#4594

On 2011-05-03, Jabba Laci <jabba.laci@gmail.com> wrote:

> I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
> 5 he says that a function that is called should be below a function
> that does the calling. This creates a nice flow down from top to
> bottom.

I generally expect the opposite: callees above, callers below, main at
the bottom.  However, that's mostly just a habit left over from C
programming where such an ordering avoids having to litter the file
with forward declarations for functions.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#4610

On May 3, 4:08 pm, Jabba Laci <jabba.l...@gmail.com> wrote:
> Hi,
>
> I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
> 5 he says that a function that is called should be below a function
> that does the calling. This creates a nice flow down from top to
> bottom.
> However, when I write a Python script I do just the opposite. I start
> with the lines
>
> if __name__ == "__main__":
>     main()
>
> Then I add main() above, which is a control function that contains
> some function calls that decompose the problem into subproblems. Then
> I add these functions above, etc.
>
> Is there a convention for this? Should main() be at the top and called
> function below?
>
> Thanks,
>
> Laszlo

I order classes and methods as I'd expect someone approaching the
program for the first time to want to read it. I think Robert Martin's
recommendation of use before declaration makes it easier to read a
program for the first time. Some compilers require declaration before
use because they need to see the declaration before they see any uses.
Python is in between: you can treat Python as if the order you write
things doesn't matter, but there are cases where it really does
matter. When it does, you have to have the definition before the use.

John Roth

[toc] | [prev] | [next] | [standalone]

#5082

On Tue, 3 May 2011 18:08:27 -0400, Jabba Laci
  <jabba.laci@gmail.com> wrote:
:  I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
:  5 he says that a function that is called should be below a function
:  that does the calling. This creates a nice flow down from top to
:  bottom.

My advice would be to order it in the same way as you would if you
were presenting the algorithm in a paper.

From such a viewpoint, it depends on whether you consider the called
names to be terms which need definitions, or operations with an
intutive purpose, merely requiring an explanation (implentation) of
how it is done.

In a paper that means that definitions must come before the theorems
and lemmata very often between the theorem and its proof.  If you
don't write papers, that may not be particularly useful :-)

In programming, it means that names which have self-explanatory name
may very well be called first and defined later.  The caller will
give a high-level view of what is going on.  The callees are building
blocks whose purpose can be understood immediately, and whose inner
workings can be sought further down the file.  Fundamental definitions
which may be as easy to implement as explain may often come first.

The question here, is didactics and not programming per se.
A simple rule does not make complex code significantly easier to read,
but a thought structure of the code (with comments and choice of names)
over-all does.

And let's not forget that calls may be circular or otherwise convolved
in a way that does not allow consistent sorting of caller before/after
callee.

-- 
:-- Hans Georg

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web