Coding style and else statements

Discussion in 'Python' started by tobiah, Aug 28, 2006.

  1. tobiah

    tobiah Guest

    def foo(thing):

    if thing:
    return thing + 1
    else:
    return -1

    def foo(thing):

    if thing:
    return thing + 1
    return -1

    Obviously both do the same thing. The first is
    possibly clearer, while the second is more concise.

    Comments?

    --
    Posted via a free Usenet account from http://www.teranews.com
     
    tobiah, Aug 28, 2006
    #1
    1. Advertising

  2. tobiah

    Jorge Vargas Guest

    On 8/28/06, tobiah <> wrote:
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > else:
    > return -1
    >
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > return -1
    >
    > Obviously both do the same thing. The first is
    > possibly clearer, while the second is more concise.
    >
    > Comments?

    if there is nothing the else will check why put it there?
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Jorge Vargas, Aug 28, 2006
    #2
    1. Advertising

  3. tobiah enlightened us with:
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > else:
    > return -1
    >
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > return -1
    >
    > Obviously both do the same thing. The first is
    > possibly clearer, while the second is more concise.


    I'm definitely in favour of the second one. For me, it's clearer to
    see that the function will definitely return something.

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Aug 28, 2006
    #3
  4. tobiah

    Sam Pointon Guest

    Bruno Desthuilliers wrote:
    > foo = lambda thing: thing and thing + 1 or -1


    The and ... or trick is buggy (what if thing == -1?) and bad style. If
    you -do- want a conditional expression, 2.5 provides one:

    thing + 1 if thing else -1

    No subtle logical bugs, and a good deal more obvious.

    On the topic of the original posting, I personally prefer the latter
    (no else clause), because too deep a level of indentation is not a Good
    Thing. However, if a redundant else: would make the code clearer
    somehow, by all means use one, because this is more a matter of
    personal taste than anything.
     
    Sam Pointon, Aug 28, 2006
    #4
  5. tobiah a écrit :
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > else:
    > return -1
    >
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > return -1
    >
    > Obviously both do the same thing. The first is
    > possibly clearer, while the second is more concise.
    >
    > Comments?
    >


    What about:

    def foo(thing):
    if thing:
    result = thing + 1
    else:
    result = -1
    return result

    and:

    foo = lambda thing: thing and thing + 1 or -1
     
    Bruno Desthuilliers, Aug 28, 2006
    #5
  6. tobiah

    Tal Einat Guest

    tobiah wrote:
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > else:
    > return -1
    >
    > def foo(thing):
    >
    > if thing:
    > return thing + 1
    > return -1
    >
    > Obviously both do the same thing. The first is
    > possibly clearer, while the second is more concise.
    >
    > Comments?


    I usually prefer the second option because it is more scalable - it is
    possible to later add code to the function to return other values
    elsewhere in its code, and still have -1 returned by default, without
    changing the original code.

    As for structure, in the second example there is a clear point at which
    the function return a value, unless some other value is return
    elsewhere. In the first one you have to comprehend the entire if-else
    statement to understand that a value will always be returned at this
    point.

    Another worthy alternative mentioned is:

    def foo(thing):
    if thing:
    result = thing + 1
    else:
    result = -1
    return result

    This is scalable as described above, and also has only one exit point,
    which makes it a much simpler function. However, it forces someone
    reading the code to backtrack from the return statement and search for
    places where "result" could be set.

    I usually start with your second example, and if I need more control
    over the returned value I change the code to use this last method.
    ("More control" could be many things - checking the value for
    debugging, applying some transformation on the returned value before
    returning it...)

    - Tal
     
    Tal Einat, Aug 28, 2006
    #6
  7. Sam Pointon a écrit :
    > Bruno Desthuilliers wrote:
    >
    >>foo = lambda thing: thing and thing + 1 or -1

    >
    >
    > The and ... or trick is buggy (what if thing == -1?)


    Yes, true - Should be:
    foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0


    > and bad style.


    Lol. Well, so what about:
    foo = lambda t: (lambda t: -1, lambda t: t+1)[bool(t)](t)

    ?-)

    (NB: don't bother answering)


    > If
    > you -do- want a conditional expression, 2.5 provides one:


    Yes, at last, and I'm glad it finally made it into the language. But 2.5
    is not here yet. The 'and/or' trick can be, well, tricky, (notably in
    this case) but it at least work with most Python versions.


    > No subtle logical bugs, and a good deal more obvious.


    Indeed.
     
    Bruno Desthuilliers, Aug 29, 2006
    #7
  8. tobiah

    Tal Einat Guest

    Bruno Desthuilliers wrote:
    > Sam Pointon a écrit :
    > > Bruno Desthuilliers wrote:
    > >
    > >>foo = lambda thing: thing and thing + 1 or -1

    > >
    > >
    > > The and ... or trick is buggy (what if thing == -1?)

    >
    > Yes, true - Should be:
    > foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0
    >

    Actually, the common work-around for this is:

    (thing and [thing+1] or [-1])[0]

    This works since non-empty lists are always considered true in
    conditional context. This is more generic, and IMO more readable.
     
    Tal Einat, Aug 29, 2006
    #8
  9. Tal Einat enlightened us with:
    > Actually, the common work-around for this is:
    >
    > (thing and [thing+1] or [-1])[0]
    >
    > This works since non-empty lists are always considered true in
    > conditional context. This is more generic, and IMO more readable.


    I think it's not readable at all. It's confusing - you create a
    singleton list, only to extract the first element from it and discard
    the list again. I'd rather read a proper if-statement.

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Aug 29, 2006
    #9
  10. tobiah

    Carl Banks Guest

    tobiah wrote:
    > def foo(thing):
    > if thing:
    > return thing + 1
    > else:
    > return -1
    >
    > def foo(thing):
    > if thing:
    > return thing + 1
    > return -1
    >
    > Obviously both do the same thing. The first is
    > possibly clearer, while the second is more concise.



    I almost always go with #2. The else clause is redundant and
    potentially misleading in the first one. (A casual programmer might
    not notice that it always returns and so add code beneath it, or a
    casual code checker might not notice that the end is unreachable, and
    flag the function as both returning a value and returning the default.)

    However, I have rare cases where I do choose to use the else (ususally
    in the midst of a complicated piece of logic, where it's be more
    distracting than concise). In that case, I'd do something like this:

    def foo(thing):
    if thing:
    return thing+1
    else:
    return -1
    assert False


    Carl Banks
     
    Carl Banks, Aug 30, 2006
    #10
  11. tobiah

    Steve Holden Guest

    Carl Banks wrote:
    [...]
    > However, I have rare cases where I do choose to use the else (ususally
    > in the midst of a complicated piece of logic, where it's be more
    > distracting than concise). In that case, I'd do something like this:
    >
    > def foo(thing):
    > if thing:
    > return thing+1
    > else:
    > return -1
    > assert False


    I think that's about the most extreme defensive programming I've seen in
    a while! I can imaging it's saved your ass a couple of times when you've
    edited the code a while after writing it.

    Of course, optimising will remove the assertions ...

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
     
    Steve Holden, Aug 30, 2006
    #11
  12. tobiah

    Ben Finney Guest

    "Carl Banks" <> writes:

    > However, I have rare cases where I do choose to use the else
    > (ususally in the midst of a complicated piece of logic, where it's
    > be more distracting than concise). In that case, I'd do something
    > like this:
    >
    > def foo(thing):
    > if thing:
    > return thing+1
    > else:
    > return -1
    > assert False


    To my eyes, that's less readable than, and has no benefit over, the
    following:

    def foo(thing):
    if thing:
    result = thing+1
    else:
    result = -1
    return result

    --
    \ "Ours is a world where people don't know what they want and are |
    `\ willing to go through hell to get it." -- Donald Robert Perry |
    _o__) Marquis |
    Ben Finney
     
    Ben Finney, Aug 30, 2006
    #12
  13. tobiah

    Tal Einat Guest

    Sybren Stuvel wrote:
    > Tal Einat enlightened us with:
    > > Actually, the common work-around for this is:
    > >
    > > (thing and [thing+1] or [-1])[0]
    > >
    > > This works since non-empty lists are always considered true in
    > > conditional context. This is more generic, and IMO more readable.

    >
    > I think it's not readable at all. It's confusing - you create a
    > singleton list, only to extract the first element from it and discard
    > the list again. I'd rather read a proper if-statement.
    >

    I agree that an "if" statement is by far more readble; I was referring
    only to the dicussion of the "and-or trick", not the entire issue.

    I meant to say that:

    (thing and [thing+1] or [-1])[0]

    is more readable (IMO) than:

    thing != -1 and (thing and thing+1 or -1) or 0

    - Tal
     
    Tal Einat, Aug 30, 2006
    #13
  14. At Wednesday 30/8/2006 04:47, Tal Einat wrote:

    >I meant to say that:
    >
    >(thing and [thing+1] or [-1])[0]
    >
    >is more readable (IMO) than:
    >
    >thing != -1 and (thing and thing+1 or -1) or 0


    Interesting to find how different persons feel "readability" - for
    me, the later is rather clear (but definitively I prefer an if
    statement), and the former simply sucks.


    Gabriel Genellina
    Softlab SRL





    __________________________________________________
    Preguntá. Respondé. Descubrí.
    Todo lo que querías saber, y lo que ni imaginabas,
    está en Yahoo! Respuestas (Beta).
    ¡Probalo ya!
    http://www.yahoo.com.ar/respuestas
     
    Gabriel Genellina, Aug 30, 2006
    #14
  15. tobiah

    Guest

    Tal Einat wrote:
    > I meant to say that:
    >
    > (thing and [thing+1] or [-1])[0]
    >
    > is more readable (IMO) than:
    >
    > thing != -1 and (thing and thing+1 or -1) or 0


    Neither is particularly readable, though I agree that the latter is
    worse since it has to have the third option ("0") on the end. But I'd
    go with an if statement unless I had a real reason to use something so
    unreadable. If you are enamored of such constructs, 2.5 will allow
    conditional expressions:

    (thing + 1) if thing else -1
     
    , Aug 30, 2006
    #15
  16. tobiah

    Carl Banks Guest

    Ben Finney wrote:
    > "Carl Banks" <> writes:
    >
    > > However, I have rare cases where I do choose to use the else
    > > (ususally in the midst of a complicated piece of logic, where it's
    > > be more distracting than concise). In that case, I'd do something
    > > like this:
    > >
    > > def foo(thing):
    > > if thing:
    > > return thing+1
    > > else:
    > > return -1
    > > assert False

    >
    > To my eyes, that's less readable than, and has no benefit over, the
    > following:
    >
    > def foo(thing):
    > if thing:
    > result = thing+1
    > else:
    > result = -1
    > return result


    For this example, yes. Actually I'd probably never do it in this
    particular case. What I mean in general is some rare times (especially
    when logic is complex) I prefer to use a redundant control statement
    that renders something non-reachable; then I use assert False there.


    Carl Banks
     
    Carl Banks, Aug 30, 2006
    #16
  17. tobiah

    Carl Banks Guest

    Steve Holden wrote:
    > Carl Banks wrote:
    > [...]
    > > However, I have rare cases where I do choose to use the else (ususally
    > > in the midst of a complicated piece of logic, where it's be more
    > > distracting than concise). In that case, I'd do something like this:
    > >
    > > def foo(thing):
    > > if thing:
    > > return thing+1
    > > else:
    > > return -1
    > > assert False

    >
    > I think that's about the most extreme defensive programming I've seen in
    > a while! I can imaging it's saved your ass a couple of times when you've
    > edited the code a while after writing it.


    1. The "assert False" is more for documenting than error checking.
    2. The right way to be defensive here is not to have redundant logic.
    The above is really something I do rarely only when some other factor
    makes the redundant logic a lesser of evils.


    Carl Banks
     
    Carl Banks, Aug 30, 2006
    #17
  18. tobiah

    Ben Finney Guest

    "Carl Banks" <> writes:

    > Ben Finney wrote:
    > > "Carl Banks" <> writes:
    > > > def foo(thing):
    > > > if thing:
    > > > return thing+1
    > > > else:
    > > > return -1
    > > > assert False

    > >
    > > To my eyes, that's less readable than, and has no benefit over,
    > > the following:
    > >
    > > def foo(thing):
    > > if thing:
    > > result = thing+1
    > > else:
    > > result = -1
    > > return result

    >
    > For this example, yes. Actually I'd probably never do it in this
    > particular case. What I mean in general is some rare times
    > (especially when logic is complex) I prefer to use a redundant
    > control statement that renders something non-reachable; then I use
    > assert False there.


    That's the readability problem I'm referring to. Why not ensure that
    there is one return point from the function, so the reader doesn't
    have to remind themselves to look for hidden return points?

    --
    \ "Dyslexia means never having to say that you're ysror." -- |
    `\ Anonymous |
    _o__) |
    Ben Finney
     
    Ben Finney, Aug 31, 2006
    #18
  19. tobiah

    Pete Forman Guest

    Ben Finney <> writes:

    > Why not ensure that there is one return point from the function, so
    > the reader doesn't have to remind themselves to look for hidden
    > return points?


    There will always be more potential return points in languages that
    support exceptions.
    --
    Pete Forman -./\.- Disclaimer: This post is originated
    WesternGeco -./\.- by myself and does not represent
    -./\.- the opinion of Schlumberger or
    http://petef.port5.com -./\.- WesternGeco.
     
    Pete Forman, Aug 31, 2006
    #19
  20. Ben Finney enlightened us with:
    > Why not ensure that there is one return point from the function, so
    > the reader doesn't have to remind themselves to look for hidden
    > return points?


    I always like to return as fast as possible, so that the reader
    doesn't have to read the entire function to figure out what happens
    with a set 'result' value.

    It also reduces the chance of bugs, since the value to be returned
    _is_ immediately returned, and hence the rest of the function can't
    corrupt it.

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Aug 31, 2006
    #20
    1. Advertising

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. Devin Panchal

    if and else statements.

    Devin Panchal, Dec 9, 2003, in forum: Java
    Replies:
    2
    Views:
    462
    Devin Panchal
    Dec 9, 2003
  2. raver
    Replies:
    6
    Views:
    399
    Joona I Palaste
    Apr 28, 2005
  3. Harry George
    Replies:
    6
    Views:
    444
    Bart Nessux
    Feb 23, 2004
  4. calmar
    Replies:
    11
    Views:
    949
    calmar
    Feb 21, 2006
  5. John Crichton
    Replies:
    6
    Views:
    290
    John Crichton
    Jul 12, 2010
Loading...

Share This Page