TRUE and FALSE
Brad Appleton
brad at SSD.CSD.HARRIS.COM
Sat Sep 1 00:06:26 AEST 1990
>And defining TRUE and FALSE tends to lead, eventually, to some
>maintenance programmer who's just (almost) learned C writing
>
> if (flag == TRUE)
>
>which of course doesn't work at all the way it looks. (Though I'll
>admit it reads well: "if flag is true...") IMHO, any "improvement"
>that would lead a novice into this sort of error is a step backwards.
>
>Of course, this is now the <n+1>st rehashing of this issue in this
>newsgroup, and it's essentially become a religious war.
I thought the whole point of having a boolean type was so that one
could write:
if ( flag1 && !flag2 )
instead of
if ( flag1 == TRUE && flag2 == FALSE ).
TRUE and FALSE have no place being part of this type of comparison in
any programming language that provides a boolean type; they are only
needed for assignment. SO why do some people insist on putting them
in logical comparisons - its redundant.
Maybe instead of #defining or enum'ing TRUE and FALSE we should
encourage doing something like:
#define SET(flag) flag = 1 /* or -1 or !0 or whatever */
#define CLEAR(flag) flag = 0
and if you want to get fancy:
#define TOGGLE(flag) flag = (flag) ? 1 : 0
(or whatever macro names you prefer) and then we would never be tempted
to use them in a comparison.
It just bothers me when I see (flag == FALSE) instead of (!flag).
I guess this is the n+2 rehashing of this tripe!
______________________ "And miles to go before I sleep." ______________________
Brad Appleton brad at travis.ssd.csd.harris.com Harris Computer Systems
...!uunet!hcx1!brad Fort Lauderdale, FL USA
~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~
More information about the Comp.lang.c
mailing list