Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Good code patterns in Python

Thread Tools

Good code patterns in Python

Michael Chermside
Posts: n/a
Will Stuyvesant writes:
> If you know that your source code is going to be used
> later by others, then I feel that code with the pattern:
> if some_condition:
> some_name = some_value
> else:
> some_name = other_value
> is often a mistake. Much better, safer, would be:
> some_name = some_value
> if not some_condition:
> some_name = other_value

I disagree with you... I think that the first form is superior
to the second. Here are two reasons.

My number one reason is readability. Seeing "some_name = some_value"
when some_name is ACTUALLY going to take on other_value is very
misleading to the reader. Particularly in Python, I strive to make
my code very readable -- it's typically more important to me to be
readable than it is to be fast. Furthermore, if the code is easily
understood, then that maintanence programmer or re-user of your
code that you mentioned is less likely to make a mistake like leaving
some_name undefined.

My second reason is the danger of this maintanence programmer. You
are concerned that they might "change or adapt the 'if' part".
Frankly, I don't find this to be much of a worry. After all, the
use of an if with an else clause CLEARLY indicates that you expect
one of these two branches to be taken, and that if they change it
so neither is taken, they'd better be sure they know what they're
doing. On the other hand, I'm QUITE worried about the maintanence
programmer modifying your second example. If they somehow fail to set
some_name it would result in "NameError: name 'some_name' is not
defined" the first time that it used -- a pretty clear error message.
But (unlike modifying the if-else), a maintanence programmer is quite
likely to simply add some new lines of code... perhaps (foolishly)
between the first assignment and the if statement. If this happened,
the resulting error would be that some_name DID have a value, but
it was the WRONG value. This could result in some peculiar exception
at an arbitrary time, or (much worse) perhaps NO exception at all...
the program would proceed, producing incorrect data with no warning.

Finally, I'd like to make reference to the wonderful world of unit
tests. If the code has no unit tests, then either error is possible.
But if there are unit tests, then the person who re-uses that code
and modifies it so that some_name is no longer set properly will
find a test failing. This will immediately alert them that their
change is causing problems... they will examine the situation and
either fix the problem or change the test ("now I WANT some_name to
be undefined in some cases").

-- Michael Chermside

Reply With Quote
Theodor Rash
Posts: n/a
Andrew Bennetts wrote:

> if cond:
> x = special_val
> else:
> x = some_val
> can be "read" more-or-less directly into English: "if the condition is
> true, then 'x' is set to 'special_val'; otherwise, 'x' is set to
> 'some_val'".
> Saying "'x' is set to 'some_val'. Now, if some condition is true, 'x' is
> set to 'special_val'" is counter-intuitive to my way of thinking.
> That said, I can readily recognise both idioms (despite having a slight
> preference for one form), so it's really a non-issue...

ACK, but I'd like to add an additional aspect:
If the if-statement should work as a real switch, that is: one branch or the
other of two equivalent branches, than it should be coded in a way that the
reader recognizes the switch at first glance, with if/else.
If the condition is brought into the code to fit some rare exception, for
example to meet some hardware requirements that might get obsolete and
thrown out again in a later stage of maintenance, then the form 'x' is
set to 'special_val' is the right way, IMHO. But it should be accompanied
with a comment that indicates the purpose of that piece of code.
Anyway, instead of speculating about how some other programmer might perhaps
interpret the code that I wrote, I give him an explicit comment and I'm
(Saw this sig somewhere: 'Comment my code?? Why do you think they call it
Reply With Quote
Max M
Posts: n/a
Theodor Rash wrote:

> (Saw this sig somewhere: 'Comment my code?? Why do you think they call it
> code?')

My favourite comment of that kind is from Bertrand Meyer, who invented
Eiffel. I dont remember it exactly, but it goes something like:

"If programmers want to read text, they should buy a cheap novel."

To his defense he was arguing that the code should be documentation in
itself. Hence programming by contract.

I guess that has been refined now by the tdd camp, where you should be
able to read what the tested code does by reading the tests.

regards Max M

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
where to find good patterns and sources of patterns (was Re: singletons) crichmon C++ 4 07-07-2004 10:02 PM
Re: Good code patterns in Python Bob Gailer Python 33 07-29-2003 04:50 PM
any good book to learn and understand design patterns Abhijit Mhatre Java 2 07-23-2003 04:15 AM
Re: Collective memory (was: Good code patterns in Python) Michael Sparks Python 2 07-07-2003 10:42 AM
Good code patterns in Python Will Stuyvesant Python 10 07-02-2003 11:30 PM