440,581 Members | 1,990 Online
Need help? Post your question and get tips & solutions from a community of 440,581 IT Pros & Developers. It's quick & easy.

# Coding style and else statements

 P: n/a 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 Aug 28 '06 #1
19 Replies

 P: n/a On 8/28/06, tobiah -- Posted via a free Usenet account from http://www.teranews.com -- http://mail.python.org/mailman/listinfo/python-list Aug 28 '06 #2

 P: n/a 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 Aug 28 '06 #3

 P: n/a 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. Aug 28 '06 #4

 P: n/a 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 Aug 28 '06 #5

 P: n/a 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. Aug 28 '06 #6

 P: n/a 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. Aug 29 '06 #7

 P: n/a 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 Aug 30 '06 #8

 P: n/a 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 Aug 30 '06 #9

 P: n/a "Carl Banks"

 P: n/a 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 Aug 30 '06 #11

 P: n/a 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 Aug 30 '06 #12

 P: n/a 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 '06 #13

 P: n/a Ben Finney wrote: "Carl Banks"

 P: n/a 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 Aug 30 '06 #15

 P: n/a "Carl Banks"

 P: n/a Ben Finney

 P: n/a Pete Forman

 P: n/a 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 I wouldn't discount: def foo(thing): result = -1 if thing: result = thing+1 return result especially if "thing" is the less expected case. This puts the "more likely" result first, followed by checks that might modify that result. But, I also try to avoid adding 1 to things that I test for Truth: >>x = 8foo(x) 9 >>foo(x>1) 2 >>foo(x and 1) 2 >>foo(x or 1) 9 --Matt Sep 1 '06 #19

 P: n/a ma***********@gmail.com writes: 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 I chose this to more clearly contrast with the example to which I was responding; same number of statements but clearer control flow. I wouldn't discount: def foo(thing): result = -1 if thing: result = thing+1 return result Yes, that would be my preferred form in most cases. If I'm writing a function that returns a value, I like to make it clear by the symmetry of 'result = DefaultValue' and 'return result' that that's the main gist of the function; the rest of the function is then geared around changing 'result' before the 'return result' statement. My way of being friendly to the reader (admittedly, assuming the reader will read code similar to the way I read it). -- \ "Sittin' on the fence, that's a dangerous course / You can even | `\ catch a bullet from the peace-keeping force" -- Dire Straits, | _o__) _Once Upon A Time In The West_ | Ben Finney Sep 1 '06 #20

### This discussion thread is closed

Replies have been disabled for this discussion.