coding standards
Christopher R. Hertel
crh at NTS.Umn.EDU
Sat May 9 02:40:17 GMT 1998
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
More information about the samba-technical
mailing list