Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: C Style
Message-ID: <3583@haddock.ISC.COM>
Date: 22 Apr 88 16:32:25 GMT
References: <11216@brl-adm.ARPA> <2111@chinet.UUCP> <4403@garfield.UUCP> <226@hotlr.ATT> <130@obie.UUCP> <5981@utcsri.UUCP> <1982@ubc-cs.UUCP> <126@atpal.UUCP> <2823@mmintl.UUCP> <255@oink.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 19

In article <255@oink.UUCP> jep@oink.UUCP (James E. Prior) writes:
>In article <2823@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>>In my opinion, things like if(variable==TRUE) are abominations.
>
>[It] is not only abominable, it can be dangerous.  var==TRUE tends to presume
>that the only valid values of var are FALSE and TRUE.

If this isn't the case, it shouldn't have been declared boolean.  My coding
style is as if `bool' were a true boolean type, and as if assigning anything
other than `YES' or `NO' (yeah, I follow Kernighan, not Wirth) would produce
undefined results.

>There are times when a var can very intentionally have a non-zero (true)
>value other than TRUE (1).  The classic kind of case of this is [isalpha].

Then isalpha() is not a boolean, in my book.  I'm not convinced there's any
good reason for this; it would be trivial to rewrite the function to return a
true boolean.  In most instances this would have zero run-time cost.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint