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?

--
Posted via a free Usenet account from http://www.teranews.com

[Tal Einat]

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

[Gabriel Genellina]

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 "readabilit y" - 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]

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

[Carl Banks]

Ben Finney wrote:

"Carl Banks" <pa************ @gmail.comwrite s:

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]

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

[Ben Finney]

"Carl Banks" <pa************ @gmail.comwrite s:

Ben Finney wrote:

"Carl Banks" <pa************ @gmail.comwrite s:

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

[Pete Forman]

Ben Finney <bi************ ****@benfinney. id.auwrites:

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
pe*********@wes terngeco.com -./\.- the opinion of Schlumberger or
http://petef.port5.com -./\.- WesternGeco.

[Ben Finney]

Pete Forman <pe*********@we sterngeco.comwr ites:

Ben Finney <bi************ ****@benfinney. id.auwrites:

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.

I was specifically referring to 'return' points, i.e. points in the
function where a 'return' statement appears.

In the example to which I responded, the function had multiple
'return' statements, and an 'assert' to aid in finding out when none
of the return statements was hit. I'm making the point that if that
effort is being taken anyway, it's more readable to allow the reader
to see only *one* explicit return at the end, and not write any more
in the first place.

--
\ "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

[matt.newville]

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 = 8
foo(x)

9

>>foo(x>1)

2

>>foo(x and 1)

2

>>foo(x or 1)

9

--Matt

[Ben Finney]

ma***********@g mail.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