Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!husc6!diamond.bbn.com!mlandau
From: mlandau@Diamond.BBN.COM (Matt Landau)
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <6833@slate.BBN.COM>
Date: Mon, 29-Jun-87 13:03:58 EDT
Article-I.D.: slate.6833
Posted: Mon Jun 29 13:03:58 1987
Date-Received: Tue, 30-Jun-87 06:22:26 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <22250@sun.uucp> <17193@cca.CCA.COM> <13008@topaz.rutgers.edu>
Reply-To: mlandau@Diamond.BBN.COM (Matt Landau)
Organization: BBN Laboratories, Inc., Cambridge, MA
Lines: 65


In comp.lang.c (<13008@topaz.rutgers.edu>), ron@topaz.rutgers.edu writes:
>and comparison to zero for things that are supposed to be returning
>a value
>	if( malloc(100) == 0 )

I tend to use NULL in this case because it has the connotation of 
a zero valued *pointer*.  Thus, seeing NULL instead of 0 clues the
reader in to the fact that it's a pointer value that is being 
tested instead of an int or a long (in which case I'd want to see
the zero written as 0L anyway).

>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.

It's an efficiency hack of sorts.  Comparison of a value to zero to
check for less than zero values is MUCH cheaper on most architectures
than comparison to an explicit -1 (which may require saving, overwriting, 
and reloading registers).  Granted, on a 68000 or a VAX, the difference 
is probably too small to notice.  But believe me, a few such efficiency 
hacks can make a BIG difference on a slow, stupid 8088!  (Yes, I've
profiled and benchmarked code on little machines when I used to do that
sort of thing professionally, and verified that even little tweaks like
this make an important difference in a frequently-executed loop.)

>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)

As with any programming language, it's all a matter of being comfortable
with the idioms.  Anyone who programs in C for any length of time, or 
who has read K&R carefully, should not be mystified by seeing

	if ((fp = fopen(foo, "r")) == NULL)

Granted, it's easier for novices or occasional programmers to read the
more verbose (pascaloid?) forms, but a language isn't designed only for
the novice.  When I'm doing serious work on large chunks of code,
what's important is expressing what's going on concisely, but clearly
to anyone who knows *the standard C idioms*.  I'd rather fit that extra
couple of lines of code on the screen or page than not.  

Besides, the single statement version may actually be EASIER to read: 
to me, it says "open this file and check to see if the fopen call 
succeeded", i.e., it's conceptually a single atomic operation, and should 
be written so as to indicate that fact.  That's how I define "writing the 
code to indicate what's going on."

On the other hand, this is all aesthetics/religion, and everyone is 
certainly entitled to his or her opinion.
-- 
 Matt Landau					"Wage Peace"
 mlandau@bbn.com