Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site rpics.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rpics!weltyrp
From: weltyrp@rpics.UUCP (Richard Welty)
Newsgroups: net.lang.c
Subject: Re: Re: more about programming style
Message-ID: <141@rpics.UUCP>
Date: Wed, 31-Jul-85 22:31:40 EDT
Article-I.D.: rpics.141
Posted: Wed Jul 31 22:31:40 1985
Date-Received: Sat, 3-Aug-85 04:52:14 EDT
References: <11457@brl-tgr.ARPA> <68@ucbcad.UUCP> <1693@reed.UUCP> <441@myriasb.UUCP>
Organization: RPI CS Department, Troy  NY
Lines: 41

> Perhaps I'm being a bit sarcastic, but could it be that the reason experienced
> C programmers often use
> 
> 	if ((fp = fopen("file", "r")) == NULL) ...
> 
> is that the compiler will complain if you write
> 
> 	if ((fp = fopen("file", "r")) = NULL) ...
> 
> whereas it won't complain about
> 
> 	fp = fopen("file", "r");
> 	if (fp = NULL) ...
> 
> ???

Actually, the = vs. == mistake has caused me to take the following
steps ...

1. #define EQ ==

2. NEVER use == directly

3. NEVER make an assignment in an if statement

The result is that any occurance of = in an if is
an error, or a reversion to an older style that should
be corrected.  It does, perhaps, make the code look a little
like fortran, but I've spent one hell of a lot less time on the
= vs. == bug since I started doing this ...

-- 
				Rich Welty

	(I am both a part-time grad student at RPI and a full-time
	 employee of a local CAE firm, and opinions expressed herein
	 have nothing to do with anything at all)

	CSNet:   weltyrp@rpi
	ArpaNet: weltyrp.rpi@csnet-relay
	UUCP:  seismo!rpics!weltyrp