Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!mcnc!rti-sel!rtp47!throopw
From: throopw@rtp47.UUCP (Wayne Throop)
Newsgroups: net.lang.c
Subject: Re: The wonders of C
Message-ID: <12@rtp47.UUCP>
Date: Sun, 24-Mar-85 13:23:26 EST
Article-I.D.: rtp47.12
Posted: Sun Mar 24 13:23:26 1985
Date-Received: Sat, 30-Mar-85 07:31:41 EST
References: <9436@brl-tgr.ARPA>
Organization: Data General, RTP, NC
Lines: 20

> Actually, there are those of who, disliking both the "="/"==" closeness
> and the "!="/"|=" closeness, use "EQ" for "==" and "NE" for "!=", which
> C allows by means of #define.
> 
> David	sde@mitre-bedford
> 
> P.S. I do, however, agree that it was ergonomically foolish to count
> relative uses of assignment vs. comparison to come up with =/== instead
> of :=/=. How many hours of debug time (and how many debug keystrokes)
> does it take, after all, to use up the marginal saving of some keystrokes in
> initial entry?
> 

It seems to me that the normally-cited "save keystrokes" reason for
the =/== choice cannot be correct.  If it were, wouldn't the choice for
the &/&& and |/|| operators be reversed?  &&'s are much more common than
&'s in almost all C code I have seen.

It also seems clear that saving keystrokes is almost never a valid concern.
What needs to be optimized is readability.  Even in the case of my own
code, let alone others, I read it much more often than I write it.