Definition of boolean

[Dave Jones]

>From article <10 at dbase.UUCP>, by awd at 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.