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

[Nick Keighley]

rogz wrote:

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.

I fail to see how the original code was "dangerous" . I tend not to
trust
a coder who thinks return expressions have to be parenthasised. I might
write the code in the form shown.

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?

who is "man", is it a new age thing? I'd respond if I understood you.
--
Nick Keighley

[rogz]

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

who is "man", is it a new age thing? I'd respond if I understood you.

Err.. You should read "one" instead of "man".

rogz

[Bart]

Nick Keighley wrote:

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?

who is "man", is it a new age thing? I'd respond if I understood you.

It's German for "one", when used as a pronoun.

Regards,
Bart.

[mark_bluemel]

rogz wrote:

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?

Well, as I recently changed a piece of code from the second format to
the first (roughly) to make it clearer and more expressive (at least in
my opinion :-), I disagree with the transformation suggested.

[Barry]

"rogz" <ro******@gmail .comwrote in message
news:45******** **@news.bluewin .ch...

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

I took a few minutes to look at the other articles posted by this fellow on
acmQueue. I wouldn't put much stock in his offerings.

[Ancient_Hacker]

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?

Now to get just one exit point TAKES A LITTLE MORE WORK and a little
more nesting or use of "break". 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;

--------------
Now I know in a large function with a lot of error checks the code can
get a bit indented.
It's a tradeoff. Personally I don't mind indenting if it makes the
code clean, flow-thruough, and with obvious entry and exit points.

Your opinion may vary.

------------------

(2) Second point, do you use positive or negative logic. Personally I
don't think it matters a whole lot whether you filter out the BAD
conditions or include in the GOOD conditions, as long as the conditions
make some kind of logical sense. The original code detected the BAD
conditions in a series of if's, saying in effect, if this or this or
this then return an error, the alternative being: if this and this and
this then do the work else various errors. I'd try to keep to one
paridigm or the other, mixing if this but not that can get confusing.

Your opinion may vary.

[Michal Nazarewicz]

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

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

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

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-

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;

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-
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl >---<jid:mina86*chr ome.pl>--ooO--(_)--Ooo--

[Richard Heathfield]

Ancient_Hacker said:

<snip>

Now I know in a large function with a lot of error checks the code can
get a bit indented.
It's a tradeoff. Personally I don't mind indenting if it makes the
code clean, flow-thruough, and with obvious entry and exit points.

Your opinion may vary.

My opinion varies, insofar as I would prefer to see a large function broken
up into smaller ones. As well as making the code simpler to understand (if
done properly!), this also has the advantage of reducing the indent level -
which, again, aids readability.

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

[Ancient_Hacker]

Michal Nazarewicz wrote:

Why not:

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;

Yep, that looks okay too, and in a sense clearer as the error condition
is right by the error code, instead of down at the end of all the
ifs().

Yet another way is to hide all the error checking and nesting in a
macro, something like:

(to just log the first error)
#define Ensure(cond,cod e) if( Answer == Okay ) if(!cond) Answer =
code; )

(to log all errors)
#define Ensure(cond,cod e) if(!cond) Answer |= code; )

Answer = Okay;
Ensure( out >= 0, BADOUT )
Ensure( permission operator, BADPERMS )
Ensure( data.len 0, BADLEN )
if( Answer == Okay )
Answer = write(...);
return Answer;
I know, a few more nanoseconds of overhead, but the upside is you lose
all the nesting, curlies, and you're encouraged to write the checks in
a consistent way. Your opinion probably varies.