Good code patterns in Python

  • Thread starter Michael Chermside
  • Start date
M

Michael Chermside

Will said:
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
 
T

Theodor Rash

Andrew said:
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
done.
(Saw this sig somewhere: 'Comment my code?? Why do you think they call it
code?')
Theo
 
M

Max M

Theodor said:
(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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top