Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!mtune!codas!novavax!murphy!dave
From: dave@murphy.UUCP (Dave Cornutt)
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <525@murphy.UUCP>
Date: Fri, 31-Jul-87 16:55:52 EDT
Article-I.D.: murphy.525
Posted: Fri Jul 31 16:55:52 1987
Date-Received: Sun, 2-Aug-87 05:16:35 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <22250@sun.uucp>
Organization: Gould CSD, Fort Lauderdale, FL
Lines: 110
Summary: I *do* consider pointers as being true or false

In article <22250@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> > When I see 
> > 
> > 	if (!p)
> > 
> > I read it as
> > 
> > 	if p is not valid then ...
> > 
> > The (!p) syntax tells me that p is among the class of items that may be
> > treated as boolean (under the C language conventions) and that we are
> > testing whether it is false.  This is not a matter of "saving characters";
> > it is a matter of classification.
> 
> But what does it mean to say that a pointer is "false"?  Pointers
> themselves really aren't Boolean; there is a boolean predicate *on* a
> pointer, namely the "is this pointer null" predicate.  

I was hoping you were going to go in a different direction here.  I
*do* like to use the constructs "if (p)" and "if (!p)"; I think that
they are quite clear in what they mean, because I do think of pointers
as being true or false: if a pointer points to something valid, then
it's a "true" pointer because you can dereference it.  If it is nil,
then it's a "false" pointer because you can't dereference it.  I think
that this is quite clear; it's not just a matter of saving a couple of
keystrokes, but that, in a large program, whenever you can say
something clearly with less text, I think it adds to the readability
of the program.  The meaning of the syntax is quite clear in both K&R
and the ANSI draft, and there should be no problems with portability
among conforming compilers.  Also, there should be no performance
difference, since any halfway decent compiler should be able to
recognize that "if (p)" and "if (p == NULL)" are the same and generate
the same code.  I do it purely because I *like* it. 

Then again, it isn't something I'm religious about.  Lots of people that
I respect write "if (p == NULL)" and I don't flame them for it.  It's
a free country, individual choice, etc...

>You could view
> the construct "p", used in a context that requires a Boolean
> expression, as really meaning "is_non_null(p)", and "!p" as meaning
> "!is_non_null(p)", or "is_null(p)".
> 
> > When I see
> > 
> > 	if (p != NULL)
> > 
> > it tells me two rather different things.  First of all it tells me that
> > p is an item for which there are one or more coded values, among which
> > is NULL, and that for all cases where p is not NULL, there is some action
> > to be taken.
> 
> All of which happen to be the case for pointers.  Are you arguing
> that "!p" is somehow better than "p != NULL"?  This is a matter of
> taste; if you do not view "!p" as shorthand for "is_null(p)", then "p
> == NULL" makes more sense as a way of writing "is_null(p)", and many
> good programmers do not view "!p" as such a shorthand.

I *do* view !p as a shorthand for p == NULL.  I could make an argument that
"p == NULL" implies that p is an enumerated type, but I really don't
believe that it does, so I won't.  

> > Secondly it tells me that the file that the statement is in
> > includes stdio.h (or that the author of the code is a dweeb.)  And that
> > should tell me that the code in this file needs stdio.h, FOR I DO NOT
> > CONSIDER IT GOOD PROGRAMMING PRACTICE TO INCLUDE INCLUDE FILES WHICH ARE
> > NOT USED.

A legitimate gripe; you run into the same if you use TRUE and FALSE.  ANSI
is going to take care of this by moving these types of things into a
separate include file which just about everything will have to include.

> Also, you didn't address the issue of
> 
> 	if (!strcmp(str1, str2))
> 

This has always been one of my pet peeves.  Even after years of C
programming experience, I still find myself sometimes looking at this
and reading it as "if str1 is not equal to str2..."  I wrote a little
function of my own which takes a string containing an operator in
between the other two arguments, so it looks something like this:

if (strcompare(str1,"==",str2))

An extremely simplistic parser decodes the operator, then strcmp is called
to actually do the compare, and the routine figures out what to return
depending on what the operator was; if the indicated operation was true,
it returns nonzero, else zero.  So,

if (strcompare(str1,"<",str2))

and

if (strcompare(str1,"!=",str2))

mean what they appear to mean.  This isn't as efficient as defining macros
to do the compare, but I think it reads a lot better.

---
"I dare you to play this record" -- Ebn-Ozn

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP:  ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
 or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessarilla