Good code patterns in Python

Discussion in 'Python' started by Michael Chermside, Jul 1, 2003.

  1. 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
    Michael Chermside, Jul 1, 2003
    1. Advertisements

  2. Theodor Rash

    Theodor Rash Guest

    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
    Theodor Rash, Jul 3, 2003
    1. Advertisements

  3. Max M

    Max M Guest

    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
    Max M, Jul 3, 2003
    1. Advertisements

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Abhijit Mhatre
  2. crichmon
    Jul 7, 2004
  3. Will Stuyvesant

    Good code patterns in Python

    Will Stuyvesant, Jul 1, 2003, in forum: Python
    Ben Finney
    Jul 3, 2003
  4. Bob Gailer

    Re: Good code patterns in Python

    Bob Gailer, Jul 1, 2003, in forum: Python
    Eric Sosman
    Jul 29, 2003
  5. Michael Sparks
    Max M
    Jul 7, 2003

Share This Page