Re: Python style guidelines

From: Heather Coppersmith (me_at_privacy.net)
Date: 03/13/04 

Date: 13 Mar 2004 08:22:35 -0500

On 12 Mar 2004 23:08:19 -0800,
jcb@iteris.com (MetalOne) wrote:

> I do not like style guidelines either. If one method can be
> factually proven better than another method, then it would make
> sense to encourage the better method. However, when this can't
> be done, then the guideline is simply based upon taste or gut
> instinct or personal preference. These all vary from person to
> person and who is to say what is correct.

Agreed.

> During my schooling I was taught to always place statements on their
> own line.
> x = 0
> y = 0
> z = 0

> I accepted this completely without thinking about it much.
> 20 years later I have finally come to realize that if (x,y,z)
> represents a point that
> x = y = z = 0 or
> (x,y,z) = (0,0,0)
> is not always so bad. It conserves lines of code, and being able to
> see more lines of code at one time is beneficial.

In python,

    x = y = z = 0
    (x, y, z) = (0, 0, 0)

is exactly two statements, so all is still well with the world. ;-)

> Some guidelines recommend functions with only a single return
> point. I don't understand why this insanity got started. At
> one point it was recognized that multiple entry points into a
> function was confusing, but why did it have to get extrapolated
> to multiple exit points. Upon entry to a function, I sometimes
> like to verify that everything is ok before proceeding and if it
> is not just get out. Parameters can validated, resources
> acquired, or whatever.

It's that "resources acquired" part that messes people up. I've
seen it over and over and over again. Memory leaks. Dangling
pointers. Unrecoverable file handles. Especially as functions
that acquire lots of resources evolve over time and someone adds
code to acquire another resource or detect another error condition
and then doesn't find all the subsequent exit points. It's less
of an issue with languages with proper garbage collection, but it
can be a real nightmare in (e.g.) C or assembler. Unit tests that
cover all possible resource leaks are difficult to construct
correctly. C++ partially addresses the problem with RIAA (if
coders use it properly) and a hodgepodge of "smart" objects that
do pseudo self-garbage collection.

A single exit point also gives me a fighting chance to add
something to the logical end of a function, like setting the "I'm
done" flag or logging the result.

If I know that my function only has one exit point, then it's also
easier to add "let's see what this function is returning"
debugging code, because I know exactly where to put it and where
to look for it later when I want to take it out. In some systems,
the fact that a given function reaches its (single) exit point is
extremely valuable information.

OTOH, I'm usually the first one to stand up at a design review and
declare that some function or some method is too long or too
complex and should be broken up *before* such problems occur.

And that all said, I agree that a bunch of pre-checks and a quick
exit, BEFORE DOING ANYTHING ELSE, near the top of a function can
make the rest of some functions much more clear. Again, I've seen
it a million times: I'll add one more validation down here, but
forget to release that memory we just acquired up there.

> At my work we currently have a guideline to always use brackets in
> "if" statements.
> if
> {
> single statement
> }
> else
> {
> single statement
> }

Yep, those guidelines are useless. Shouldn't we spend our code
review time doing something productive?

> And so it goes. I guess I am a believer in TIMTOWTDI.

The more code I read, the more I wish people would use the
*obvious* way. ;-)

> The other thing about guidelines is that once somebody publishes
> a book with guidelines, lookout. Your employer may soon have
> you following them all whether you agree with them or not.
> Rational Rose and UML are great examples of this, but that is
> another story.

Yes it is, and I have lived it. Eeuuww.

Regards,
Heather 

-- 
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

Relevant Pages

  • Re: Unexpected exit of pthread
    ... keep resources around even when functions return. ... TSD with a destructor. ... The only STANDARD ways defined by the POSIX STANDARD that a THREAD can exit are pthread_exit except in the initial thread where it's exit) and delivery of a cancellation request to the thread. ... POSIX once considered a "pthread_abort" interface that would force immediate termination of another thread; and while it was rejected by POSIX any vendor might choose to implement something like that. ...
    (comp.programming.threads)
  • Re: proper way to daemonize
    ... On Apr 24, 2009, at 12:11 PM, James Gray wrote: ... as it will call all "at_exit" handlers in the ... What resources are you talking about? ... By the time exit is called, ...
    (comp.lang.ruby)
  • Re: performance implications of releasing resources and context switches
    ... Ambrose Silk wrote: ... and closecalls and letting them be handled by _exit() instead. ... you risk tying up or running out of resources. ... of the program using mmap/munmap and about 1.3 seconds ...
    (comp.unix.programmer)
  • Re: performance implications of releasing resources and context switches
    ... and closecalls and letting them be handled by _exit() instead. ... you risk tying up or running out of resources. ... The core of what it does is checksumming files. ... Now, why there are ~6K extra mmap calls and only ~2K extra munmaps, and ~5K more opens vs ~8K more closes, is a very interesting question which I'm looking into. ...
    (comp.unix.programmer)
  • Re: Exit query if @@rowcount > 0
    ... If you mean to exit a batch or stored procedure, ... query is a single statement, so there is nothing to exit from). ... Be aware that you must check @@rowcount ... How would this work in a DTS Execute SQL ...
    (microsoft.public.sqlserver.programming)