Coding style and else statements

[tobiah]

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?

 

[Jorge Vargas]

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?

 

[Sybren Stuvel]

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

 

[Sam Pointon]

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.

 

[Bruno Desthuilliers]

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

 

[Tal Einat]

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

 

[Bruno Desthuilliers]

Sam Pointon a écrit :

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.

 

[Tal Einat]

Sam Pointon a écrit :

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.

 

[Sybren Stuvel]

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

 

[Carl Banks]

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

 

[Steve Holden]

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

 

[Ben Finney]

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

 

[Tal Einat]

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

 

[Gabriel Genellina]

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

 

[sjdevnull]

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

 

[Carl Banks]

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]

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

 

[Ben Finney]

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?

 

[Pete Forman]

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

 

[Sybren Stuvel]

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