Python style guidelines

[Mel Wilson]

Re: Python style guidelines

In article <c2rafr$21ftn5$ 1@ID-169208.news.uni-berlin.de>,
"Greg Ewing (using news.cis.dfn.de )" <wmwd2zz02@snea kemail.com> wrote:[color=blue]
>John Roth wrote:[color=green]
>> I suspect that's a rather common error. I'd much prefer
>> that both find and index return an object that acted like
>> a number but returned the logically correct response when
>> queried as a boolean: true for zero and false for -1.[/color]
>
>Good heavens, no! That would be a *massively* dangerous
>object to have floating around in one's program...[/color]

*Most* of them wouldn't float very far.. I presume that
when you did arithmetic on one of them, the magic wouldn't
metastatize to the result. So when one did escape from the
find/index context it would be the last thing anybody
expected.

Regards. Mel.


ob. c.l.p. fear, surprise

[Jorgen Grahn]

Re: Python style guidelines

On Thu, 11 Mar 2004 17:39:31 -0500, Will Berry <wberry@wberry. org.x> wrote:[color=blue]
> Style guidelines and coding standards are the devil! I would enjoy
> nothing more than reading an ACM paper entitled "Coding Standards
> Considered Harmful". I've never seen a single real-life case where the[/color]

Not an ACM paper, but ...

http://www.algonet.se/~jgrahn/anticodingrules.pdf

Disclaimer: it's an unfinished draft, and it was written in anger
during a period when I was ruled by a really stupid standard.
[color=blue]
> argument for coding standards for that reason. Or, for large projects
> and open source projects, have an auto-styler run on all checked-in
> code. That would at least do away with the spaces-or-tabs problem.[/color]

Argh! An auto-styler is the only thing I would hate more than a coding
standard... Coding style is style. People have style, programs do not.

/Jorgen

PS. I just read that PEP for the first time, and it's one of the most
reasonable style guides I've seen (meaning I already did most of that ;-).

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[MetalOne]

Re: Python style guidelines

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.

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.

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.

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

Simply on the basis that somebody might forget the braces when adding
another statement to the block. Has this ever actually happened?
What about actually testing the code? It is not too onerous of a
guideline, but it does increase lines of code, which affects the
ability to easily see more code, which affects overall readability in
some cases.

Even the usual guideline of placing statements on separate lines I
think is sometimes a mistake.
if cond: statement
elif cond: statement
else: statement

does not always seem too bad to me where you always just have a single
statement.

Somebody once convinced me that I should always use descriptive
unabreviated variable names. At first this advice seemed a little
strange to me. Most code that I had ever encountered abreviated
variable names. Vowels tend to be left out. I think it might be a
FORTRAN hold over where variables had to be 6 characters or less or
was it 8. After a while, I realized people do things like
cnt, instead of count. sz instead of size. tmr instead of timer. I
finally agree that long unabbreviated names are better. Years later,
I realize that expressions can be hard to read with long variable
names. It occurs to me that mathematics always use one character
variables like x,y,z or the greek symbols. Expressions are just
easier to read. You can simply comment what 'x' means. So variable
length is not always so simple to decide upon.

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

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.

[Heather Coppersmith]

Re: Python style guidelines

On 12 Mar 2004 23:08:19 -0800,
jcb@iteris.com (MetalOne) wrote:
[color=blue]
> 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.[/color]

Agreed.
[color=blue]
> During my schooling I was taught to always place statements on their
> own line.
> x = 0
> y = 0
> z = 0[/color]
[color=blue]
> 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.[/color]

In python,

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

is exactly two statements, so all is still well with the world. ;-)
[color=blue]
> 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.[/color]

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.
[color=blue]
> At my work we currently have a guideline to always use brackets in
> "if" statements.
> if
> {
> single statement
> }
> else
> {
> single statement
> }[/color]

Yep, those guidelines are useless. Shouldn't we spend our code
review time doing something productive?
[color=blue]
> And so it goes. I guess I am a believer in TIMTOWTDI.[/color]

The more code I read, the more I wish people would use the
*obvious* way. ;-)
[color=blue]
> 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.[/color]

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

Regards,
Heather

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

[MetalOne]

Re: Python style guidelines

> It's that "resources acquired" part that messes people up. I've[color=blue]
> 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.
>[/color]
Good points.
With resource acquistion, I was mainly thinking along the lines of

int file_compare(co nst char *filename1, const char *filename2)
{
FILE *infile1 = fopen(filename1 , "r");
FILE *infile2 = fopen(filename2 , "r");
if (!infile1 || !infile2)
{
// error
if (infile2)
fclose(infile2) ;
if (infile1)
fclose(infile1) ;
return FAILURE;
}

// compare files
return SUCCESS
}

as opposed to

int file_compare(co nst char *filename1, const char *filename2)
{
int result = SUCCESS;
FILE *infile1 = fopen(filename1 , "r");
if (infile1)
{
FILE *infile2 = fopen(filename2 , "r");
if (infile2)
{
// compare files
}
else
{
result = FAILURE;
}
}
else
{
result = FAILURE;
}
if (infile2)
fclose(infile2) ;
if (infile1)
fclose(infile1) ;
return result;
}

[Greg Ewing (using news.cis.dfn.de)]

Re: Python style guidelines

MetalOne wrote:[color=blue]
> I finally agree that long unabbreviated names are better. Years later,
> I realize that expressions can be hard to read with long variable
> names. It occurs to me that mathematics always use one character
> variables like x,y,z or the greek symbols.[/color]

I think the important thing is not to use *arbitrary*
abbreviations. There is usually more than one plausible
way to abbreviate a long word to a medium-size word.
Remembering that it's abbreviated and exactly how it's
abbreviated is a cognitive burden that one can do without.
Deciding on no abbreviations cuts out a whole lot of
degrees of freedom that provide little benefit.

Extremely short names in the mathematics style are something
else, I think -- not so much abbreviations as a different
approach to naming altogether. It often makes sense,
especially if the names tie in with symbols used in
mathematics literature on the subject.

Also, local names are different from global ones. It
probably doesn't matter much what sort of names you
use locally, but global ones need to be as memorable
as possible. Descriptive, fully-spelled-out names
seem to be best for that.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Andy Salnikov]

Re: Python style guidelines


"MetalOne" <jcb@iteris.com > wrote in message
news:92c59a2c.0 403131328.54210 c30@posting.goo gle.com...[color=blue]
> Good points.
> With resource acquistion, I was mainly thinking along the lines of
>
> int file_compare(co nst char *filename1, const char *filename2)
> {
> FILE *infile1 = fopen(filename1 , "r");
> FILE *infile2 = fopen(filename2 , "r");
> if (!infile1 || !infile2)
> {
> // error
> if (infile2)
> fclose(infile2) ;
> if (infile1)
> fclose(infile1) ;
> return FAILURE;
> }
>
> // compare files
> return SUCCESS
> }
>
> as opposed to
>
> int file_compare(co nst char *filename1, const char *filename2)
> {
> int result = SUCCESS;
> FILE *infile1 = fopen(filename1 , "r");
> if (infile1)
> {
> FILE *infile2 = fopen(filename2 , "r");
> if (infile2)
> {
> // compare files
> }
> else
> {
> result = FAILURE;
> }
> }
> else
> {
> result = FAILURE;
> }
> if (infile2)
> fclose(infile2) ;
> if (infile1)
> fclose(infile1) ;
> return result;
> }[/color]


Latter version has an error - scope of infile2 is the first if _only_.
Write it like
this (and this is my preferred style too :)

int file_compare(co nst char *filename1, const char *filename2)
{
int result = FAILURE;
FILE *infile1 = fopen(filename1 , "r");
if (infile1) {
FILE *infile2 = fopen(filename2 , "r");
if (infile2) {
// compare files
result = SUCCESS ; // maybe
fclose(infile2) ;
}
fclose(infile1) ;
}
return result;
}

// Andy.

[Rocco Moretti]

Re: Python style guidelines

Heather Coppersmith wrote:
[color=blue]
> On 12 Mar 2004 23:08:19 -0800,
> jcb@iteris.com (MetalOne) wrote:[/color]
[color=blue][color=green]
>>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.[/color]
>
>
> 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.[/color]

Unfortunately, the way I've seen "single exit points" handled in complex
functions is either to use a flag variable, which may or may not
correspond to the temporary variable for storing the return value, or to
enclose the whole function in an try: except block, raising a
specialized exception to quit. Neither of these is too elegant in my
opinion, and runs into the same problems seen with breaking out of
deeply nested loops. (A suggestion for which on a recent thread, BTW,
was to put them in a function and use return from multiple points).

Perhaps someone should write up a PEP:

def fun(params):
#Function body
finally:
#Cleanup code

Disavowing-all-responsibility-(Unless-Guido-likes-it)-ly'rs

-Rocco