Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!ulysses!sfmag!sfsup!mpl
From: mpl@sfsup.UUCP
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <1571@sfsup.UUCP>
Date: Tue, 30-Jun-87 09:27:25 EDT
Article-I.D.: sfsup.1571
Posted: Tue Jun 30 09:27:25 1987
Date-Received: Thu, 2-Jul-87 00:53:43 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <13008@topaz.rutgers.edu>
Organization: AT&T-IS, Summit N.J. USA
Lines: 80
Summary: pet peeves?  What's MY opinion, I'd like to know :{)

In article <13008@topaz.rutgers.edu>, ron@topaz.rutgers.edu.UUCP writes:
> I have always wondered why people think NULL is more mnemonic than 0.
> When I read them as exactly the same (and fortunately in C, they are
> defined to be).  I also wonder about people who define TRUE to be any
> thing, since it leads to things like
> 	if( bool == TRUE )
> which is different than
> 	if(!bool)

I define TRUE to be 1, so I can say things like
	if (blah) {
		do some pocessing
		return TRUE;
	}
	return FALSE;

I also think NULL *is* more mnemonic than 0, since when I see
	if (p == NULL) /* which I always use rather than if (!p) */
it is clear that I am doing a *pointer* test rather than any other type.

> Generally, I use !p when I'm dealing with things that are supposed
> boolean values like
> 
> 	if(!isdigit(c))

right on!

> and comparison to zero for things that are supposed to be returning
> a value
> 	if( malloc(100) == 0 )

also right on, but I'd prefer to use NULL for malloc.  I insist on
	if (strcmp(a, b) == 0)
however, since strcmp returns an integer, *not* a boolean.

> MY PET PEEVES:
> 
> 1.  Comparing error returns from UNIX syscalls to be less than zero.
>     UNIX system calls that return ints, are usually defined to return
>     -1 on error.  It drives me crazy to see code test for less than
>     zero.  It doesn't say returns negative value on error, it says
>     -1.

If you read "The Elements of Programming Style" by Kernighan and Plauger (?)
(which you may or may not agree with), the authors suggest that a test for
< 0 is better than a test for -1, since a coding error could possibly cause
a function to return a value that is out of the legal range (> 0) but is not
the intended error value (-1).  Not only that, but on many machines, a test
for < 0 may be more efficient than a test against a specific value.  I know,
this s just fluff, but I think it makes a program more readable to test for
out-of-range conditions rather than a specific value:
	n = foo(bar);
	if (n != -1)
		a = goo[n];
		/* oh, I guess goo[-2] is legal, or am I *that sure*
		   foo could *never* return -2? */

> 2.  Needless use of the comma operator and parenthesis to demonstrate
>     manhood to the obliteration of code readability, e.g.
> 
> 	    if((fd=open("foo",1)<0)
> 
>     SCREW this, too difficult, how about writing the code to indicate
>     what is going on:
> 
> 	    fd = open("foo", 1);
> 	    if(fd == -1)
> -Ron

Oh, but this is one of the things that makes C beautiful.  Granted, the comma
operator should rarely be used outside of #defines (where it is useful to
get some things to work).  However, I find
	if ((fd = open("foo", 1)) < 0)
*more* readable than
 	    fd = open("foo", 1);
 	    if(fd == -1)
since what I want to test is the return of open, *not* fd.  The "fd =" is
only there so I can capture the value to use it later.

Mike