Re: if clause
- From: Chris Dollin <chris.dollin@xxxxxx>
- Date: Tue, 31 Oct 2006 07:52:16 +0000
Richard Heathfield wrote:
Eric Sosman said:
<snip>
Insisting that all modes of failure and all modes of success
must somehow filter down to one great holy return statement is
not good practice, but monotheism run rampant. "Thou shalt have
no RETURN before Me" -- pfui!
Pfui schmui. This isn't about religion, but about clarity. If we can write
the code in a way that a maintenance droid will be able to understand
easily in five years' time, then that's a Good Thing. Personally, I find
code easier to understand if it doesn't arbitrarily leap off a cliff under
certain conditions, at apparently random intervals.
The thing that put me off multiple returns was not success/failure -
bail-out code is easy to understand, and the only caveat is "was it a clean
failure?" (e.g. let's remember to clean up memory, close any files that
shouldn't be open if the operation failed, etc etc). Rather, it was when I
was having to modify long-winded financial calculations that had return
statements sprinkled liberally through the (oversized) function.
Unravelling the "let's squeeze the last nanosecond out of this mainframe"
code so that I could do the mod properly was an exercise in torture. And
one of the worst culprits was this "oh, look, we're in six levels of loop,
this seems a suitably arbitrary place, so let's return the value of this
badly named variable. Or perhaps we should wait until we get to the next
loop, where we can return the value of an *even more* badly named
variable!"
I wouldn't want to put anyone through that. So I don't.
Arguing that X is bad because you've seen bad examples of X isn't
very convincing, unless you can show that there are no /good/
examples of X.
The code you describe apparently fails the clarity test in at least
two other ways. (fx:assert) Code that /didn't/ fail those clarity
tests and used multiple returns can still be clear.
--
Chris "hashed up hashing" Dollin
"Who are you? What do you want?" /Babylon 5/
.
- Follow-Ups:
- Re: if clause
- From: Richard Heathfield
- Re: if clause
- References:
- if clause
- From: rogz
- Re: if clause
- From: Ancient_Hacker
- Re: if clause
- From: Eric Sosman
- Re: if clause
- From: Richard Heathfield
- if clause
- Prev by Date: Re: C exe on winXP memory limitation
- Next by Date: Re: assembly in future C standard
- Previous by thread: Re: if clause
- Next by thread: Re: if clause
- Index(es):
Relevant Pages
|
|