Python style guidelines

[Heather Coppersmith]

On 12 Mar 2004 23:08:19 -0800,
jcb at 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