Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!csd4.csd.uwm.edu!markh
From: markh@csd4.csd.uwm.edu (Mark William Hopkins)
Newsgroups: comp.lang.c
Subject: Re: When do you use "if ( a = b )"? (was Re: Funny mistake)
Message-ID: <10655@uwm.edu>
Date: 1 Apr 91 02:46:56 GMT
References: <1991Mar18.195351.11985@unlv.edu> <11109@dog.ee.lbl.gov> <15053@ganymede.inmos.co.uk>
Sender: news@uwm.edu
Organization: University of Wisconsin - Milwaukee
Lines: 33

In article <15053@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill) writes:
>To me it is clear that using assignments inside conditions is very bad
>style because it makes the intention of the original programmer unclear.

Then render this in a suitable format that avoids needless redundancy:

if ((A = f1()) != 2 || (A = f2()) != 3 || (A = f3()) != 4)
   f4(A);
else
   Error(A);

I believe that your proposed definition of clarity would be turned on its head
with this example.

Mixing imperatives with expressions accords well with the style of natural
language (as opposed to a purely logical style), and thus can read better.
This especially goes for the logical operators, which actually translate
better as natural language connectives (with all its temporal connotations)
than pure logic connectives (e.g. and = and then).

Witness this classic (I saw something like it in YACC source):

                   (A = new-object()) || Error(A);

Translation: "Make a new object or bust."

Or...
	    (Op = FindOp(S)) && return Op->Type ||
	    (Sym = NewSym(S)) && return Sym->Index;

Translation:
   "Find an operator to match the string S and return its type,
    or make a symbol to match S and return its index."