if clause

[rogz]

Hello,

i have a question about "design" issues in C.

In ACMqueue of february
(article here:
http://www.acmqueue.org/modules.php?...owpage&pid=364
), KV says:

A dangerous if clause is one in which the code you want to protect
with the if isn't really protected. Consider the following pseudocode:

0: if (out < 0)
1: return (fileError)
2:
3: if (permission < operator)
4: return (permissionErro r)
5:
6: if (data.len() <= 0)
7: return (dataError)
8:
9: write(out, data, data.len)

(...)
The reason that all the if statements were added was to protect
the program from calling the write() function when there was
a problem, so the code should be structured in just that way:

0: if ((out >= 0) && (permission >= operator) && (data.len() 0))
1: write(out, data, data.len)
2: // Put all the error condition returns here.

In my mind, man can argue with the latter code, man has to copy the error
checks
and have twice the same code. What do you thinks about this code snippet?
Thanks for your replies,

rogz

[Clever Monkey]

Ancient_Hacker wrote:

rogz wrote:

>>0: if (out < 0)
1: return (fileError)
2:
3: if (permission < operator)
4: return (permissionErro r)
5:
6: if (data.len() <= 0)
7: return (dataError)
8:
9: write(out, data, data.len)

There are several disparate issues with this code and the original
writer wasnt very good at pointing them out. Here's my view:

(1) Some people think a function should have just ONE clear exit
point, at the bottom. I realize that can get a bit long-winded, but it
can make the code MUCH CLEARER, much easier to set breakpoits, much
easier to add code you're SURE will get run every time. Multiple entry
points went out with FORTRAN II, why do we still have multiple exit
points in this 21sh century?

This is certainly a common opinion, but the code I maintain embraced the
other approach: if you have special cases while setting up the main meat
of the function that suggest that continuing makes no sense, then bail
out early.

We have a whole runtime-enabled logger system so, as long as you log the
entry and exit, debugging is easy and the code is easy to read.

Once we get into the main logic for the function we usually have the
usual assortment of breaks to ensure that there is only one more exit
point to be had.

The other approach I've seen is to have all the special cases handled by
a number of "goto early" or "goto error", where the return is normalized
and control short-circuited to the exit point.

All of these approaches make sense under the right circumstances, but
this maintenance drone prefers code that can be easily read,
top-to-bottom, to figure out what it is *supposed* to do so the bugs are
easier to find.

Freeing up my cognitive energy by being able to discard early control
paths as I go really helps me solve some obscure problems. It also
allows one to say with accuracy that some variable or parameter is in
some known range (e.g., some value is or is not null, or some parameter
cannot possibly be 0, &etc.) after some specific point.

I'm speaking as someone who might not be able to run a debugger on live
code (I maintain chunks that are compiled with older compilers that have
crufty debuggers that don't run on later releases of Windows, for example).

[Al Balmer]

On 30 Oct 2006 06:17:28 -0800, "Ancient_Hacker " <gr**@comcast.n et>
wrote:

>(1) Some people think a function should have just ONE clear exit
point, at the bottom. I realize that can get a bit long-winded, but it
can make the code MUCH CLEARER, much easier to set breakpoits, much
easier to add code you're SURE will get run every time. Multiple entry
points went out with FORTRAN II, why do we still have multiple exit
points in this 21sh century?

Because in some circumstances, it makes the code much clearer, much
easier to set breakpoints, and much easier to add code to individual
tests.

IOW, "some people" are not always right. In the example given, I would
prefer the form presented as a bad example :-)

BTW, what do multiple entry points have to do with multiple exit
points?

--
Al Balmer
Sun City, AZ

[Bill Medland]

Michal Nazarewicz wrote:

>>>0: if (out < 0)
1: return (fileError)
2:
3: if (permission < operator)
4: return (permissionErro r)
5:
6: if (data.len() <= 0)
7: return (dataError)
8:
9: write(out, data, data.len)

Makes me feel uncomfortable

>
"Ancient_Hacker " <gr**@comcast.n etwrites:

>(1) Some people think a function should have just ONE clear exit
point, at the bottom. I realize that can get a bit long-winded, but it
can make the code MUCH CLEARER,

I agree totally, especially when maintaining code that has grown to a
hundred lines per function.

>
Or much less clear when it comes into nesting ifs which, IMO, is less
readable then returning when error condition occurs.

which is why I prefer "exceptions first with else if" or goto error exit

>

>much easier to set breakpoits, much
easier to add code you're SURE will get run every time. Multiple entry
points went out with FORTRAN II, why do we still have multiple exit
points in this 21sh century?

I believe, I've heard about some research showing that programmers
tend to make less errors when they are allowed to use 'break' - maybe
the same goes to multiple exit points.

>Now to get just one exit point TAKES A LITTLE MORE WORK and a little
more nesting or use of "break".

Isn't "break" really cheating? Like in:

#v+
answer;
do {
some stuff;
if (error 1) {
answer = error1;
break;
}
some stuff();
if (error 2) {
answer = error2;
break;
}
some stuff;
if (error 1) {
answer = error2;
break;
}
some stuff;
answer = success;
} while (0);
return answer;
#v-

I would say yes, since it can easily be handled with a reasonable amount of
indenting (and if it can't then it's time to consider two smaller
functions)

>
It looks just like the same function with many exit points but
uglier.

Just showing my point of view though.

>Personally I'm a nervous nelly and won't use "break" (see ATT $400
million looss due to the vagaries of "break"). So I end up with
code like the stuff below. Your opinion may vary. :

ErrorType Answer;
if( out >= 0 ) {
if( permission >= operator ) {
if( data.len 0 ) {
Answer = write( ....) 0;
} else Answer = BADLEN;
}
else Answer = BADPERMS;
} else Answer = BADOUT

return Answer;

For that depth that would satisfy me

>
Why not:

#v+
ErrorType Answer;
if (out<0) {
Answer = BADOUT
} else if (permission<ope rator) {
Answer = BADPERMS;
} else if (data.len<=0) {
Answer = BADLEN;
} else {
Answer = write(...) 0;
}
return Answer;
#v-

although I prefer that

>

And then, of course, since I prefer data-oriented to process-oriented, there
is
Answer = out < 0 ? BADOUT :
permission < operator ? BADPERMS :
data.len() <= 0 ? BADLEN :
write(...) <= 0 ? BADWRITE :
SUCCESS;
--
Bill Medland

[Eric Sosman]

Ancient_Hacker wrote:

>
(1) Some people think a function should have just ONE clear exit
point, at the bottom. I realize that can get a bit long-winded, but it
can make the code MUCH CLEARER, much easier to set breakpoits, much
easier to add code you're SURE will get run every time. Multiple entry
points went out with FORTRAN II, why do we still have multiple exit
points in this 21sh century?

Because there's one reason to enter a function ("Do this
specified thing") but many reasons the function might not be
able to do its job ("Logarithm of negative number" or "File
not found" or "Inauspicio us lunar phase").

Even the "not do its job" part is suspect: Some functions
can succeed in multiple different ways. "Item was present in
hash table" or "Item was not present but was inserted" or
"New file opened for output" or "Old file erased and truncated
to zero length, now ready for output."

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!

--
Eric Sosman
es*****@acm-dot-org.invalid

[Richard Heathfield]

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

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/

[Richard Heathfield]

Chris Dollin said:

Richard Heathfield wrote:

<snip>

>>
The thing that put me off multiple returns was [...]

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.

I'm not trying to argue that X is bad. I'm just pointing out that in *my*
experience I find X hard to maintain in general terms, and consequently I
don't like to inflict X on other people (including myself). Clarity takes
precedence over religion.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

Richard Heathfield wrote:

Chris Dollin said:

>Richard Heathfield wrote:

<snip>

>>>
The thing that put me off multiple returns was [...]

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.

I'm not trying to argue that X is bad. I'm just pointing out that in *my*
experience I find X hard to maintain in general terms, and consequently I
don't like to inflict X on other people (including myself). Clarity takes
precedence over religion.

I think we agree on that last sentence. And, in practice, I suspect
our code might be more alike than disputes like this might suggest.

Is "Clarity takes precedence over religion." a religion?

--
Chris "(fx:quack) diagonal" Dollin
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

[Richard Heathfield]

Chris Dollin said:

Richard Heathfield wrote:

<snip>

>Clarity takes precedence over religion.

I think we agree on that last sentence. And, in practice, I suspect
our code might be more alike than disputes like this might suggest.

I suspect you're right. All well-maintained roads lead to clarity.

Is "Clarity takes precedence over religion." a religion?

It's not clear.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Spoon]

Ancient_Hacker wrote:

Multiple entry points went out with FORTRAN II, why do we still have
multiple exit points in this 21sh century?

One can use setjmp() and longjmp() to create multiple entry points.

Or is that different?