djones@megatest.UUCP (Dave Jones) (02/08/89)
From article <10@dbase.UUCP>, by awd@dbase.UUCP (Alastair Dallas): > We've discussed the proper definition of NULL a great deal, and I understand > that the ANSI standard now specifies it. But what about a boolean type? > Please excuse me if the standard discusses this as well, but I can think > of several ways to handle booleans (and I've worked on code that used all > three): > > 1. typedef short bool; > > 2. typedef char bool; > > 3. typedef enum {FALSE=0, TRUE=1} bool; > > I like the last one... So do the folks who work for a certain quickly growing workstation manufacturer. They also like things like these: typedef enum {False=0, True=1} bool; #define TRUE (0==0) #define FALSE (1==0) #define TRUE (1==1) #define FALSE (0==1) #define True 1 #define False 0 etc.., etc.., etc... So if you try to #include files from various packages into one source file, you get various type-mismatch and multiple-defined messages. Grrrrr. I used to define a type called "Bool". But since I have cut down on SLMs, I just declare things "int", or whatever, and put a comment if I think such is waranted. Naming variables descriptively, and accurately documenting usage of variables is invaluable, and (in my humble opinion), better than a jillion SLMs. int thing_is_predicate; /* Boolean. Is true between calls to * [some class of routines] iff the * [thing] is currently [predicate]. */ I try to use the word "is" somewhere in the name of a boolean. (BTW, In LISP, the convention is to tag them with "-p", which stands for "predicate".) If I feel that using an SLM such as "TRUE" will help readability, (which is seldom), I'll declare it right there in the source file, *not* in an include-file that could have a cpp-fight with somebody else's include-file, and which would obligate the reader to chase it down, just to be sure I did not pull a stunt like defining "TRUE" as -1 or something. Sidebar on comments: Comments in code are usually not much more than clutter. Very often they are just notes that the writer wrote to himself to remind himself of where he was. I don't need comments like that. But even comments which are hand-crafted for you the viewer usually miss the mark. They go into too much detail about *how* something is done, rather that *what* is done, and what that *means* to the overall program data and control flow. (Sometimes I get the feeling that the writer is trying to showcase his technique by describing how clever it is.) But if you know what the variables are supposed to mean, then you know what the routine *has* to do. And comments in code often go stale: Somebody makes a change to the code, but does not change the comment. But comments on variables and data-types have long self-lives.
rkl1@hound.UUCP (K.LAUX) (02/11/89)
I have found the following to be helpful with what I call 'Logical'
states:
#define RESET -1 /* this is actually Tri-stated */
#define UNSET 0
#define SET 1
short flag = UNSET;
...
if (flag == UNSET) { /* or == SET or == RESET */
...
}
and so on...
--rkl