Path: utzoo!mnetor!uunet!husc6!yale!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: comp.lang.c
Subject: Re: == vs =
Message-ID: <3217@bunker.UUCP>
Date: 23 Jan 88 00:21:07 GMT
References: <11383@brl-adm.ARPA>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, an Olivetti Company, Shelton, Ct
Lines: 50

In article <11383@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>In article <3208@bunker.UUCP> "Gary M. Samuelson" <bunker!garys> writes:
>>4.  While it may be true that typing "mian" for "main" is as likely as
>>	typing "=" for "==", the linker will tell me that I mispelled
>>	"main" by reporting "undefined symbol."  Neither the compiler,
>>	the linker, nor lint (of which I am an ardent advocate) will
>>	tell me if "=" should be "==".

>What `lint' does and what it *should* or *could* do are not the same.
>There is no reason why `lint' could not be made to (optionally)
>complain about assignments in certain contexts.  I think Turbo C
>already has this capability.

Agreed; now suppose that lint is so changed, and gives me a warning
for each occurence of "if( x = y )" -- now what?  I *still* have
to divine the writer's intent.

>In addition, as I've already suggested, a simple "#define EQ =="
>provides another solution to this problem.

Agreed; that is another solution to this problem.  It's in the
same general class as my suggestion -- standardized coding style.

>>5.  When I see "if (x = fn())", I know what it means, but sometimes I
>>	am not sure whether the author meant "if (x = fn())" or
>>	"if (x == fn())". I spend a lot of time trying to figure out
>>	what other programmers meant, even after I figure out what
>>	they wrote.  "if( (x = fn()) != 0 )" is longer, but it is
>>	totally unambiguous to both the author and the (human) reader.

>I have yet to see an uncontrived situation in which it was hard to
>determine which was meant.  But if you really want to make it obvious,
>how about "if (x = fn(), x)"?  It's not as long, is also unambiguous,
>and has fewer parens, which I think hinder readability.  

Current discussions would seem to indicate that the comma operator
is a bigger hindrance to readability than parens (which, I agree,
can get out of hand).  A more serious problem is that 'x' may be
a non-trivial expression, involving, for example, pointers, members,
and possibly side-effects.  'x' may be a macro; in which case I
don't want it evaluated twice.

If you consistently use EQ for "==", I will have no difficulty
(on this point, at least) reading your code.  If I consistently
write the explicit test for zero, I don't think you will have
difficulty reading mine, either.  Actually, instead of the literal
'0', I usually use a more meaningful symbol.  But that's another
topic.

Gary Samuelson