coding standards

[Christopher R. Hertel]

While I generally agree regarding these specifics I think that reasons
should be provided, otherwise it's just dogma.  In many cases the
reasoning is pretty obvious, but I'm not afraid to regurgitate the
obvious, so... 

> if (boolean == True) is bad: this should be if (boolean)

The reason for this is that a boolean type is generally some form of int. 
The type itself may have more than two possible values.  Exceptions would
be a on-bit bitfield or an typedef'd enum.  Even so, the

  if( boolean )

construct will always work, while the

  if( TRUE == boolean )

construct may not produce the desired results.

> if (boolean)
> {
> 	flag = True;
> }
> else
> {
> 	flag = False;
> }
> 
> should be flag = (boolean);

Maybe.  I sometimes go with

  flag = (boolean) ? TRUE : FALSE;

Which normalizes the result.  It doesn't "improve" the result (i.e., make
it more correct), so the caution above is quite valid.  In general, I will
normalize function return values, but that's because most of the functions
I write will be called by programs other people write and I have no
control over their coding style (which is as it should be).

> void *ptr = 0 is bad: this should be void *ptr = NULL

As Andrew pointed out to me, the C standard does define NULL as a pointer
with a value of zero.  void *ptr = 0 isn't wrong, per se., it's just that 
it's much clearer to use NULL.

A quick grep through /usr/include on my Linux box shows that NULL is 
typically defined as 

#define NULL ((void*)0)

So the typecasting is done for you.

Chris -)-----

--
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services