Newsgroups: comp.lang.c
Path: utzoo!sq!dak
From: dak@sq.sq.com (David A Keldsen)
Subject: Re: One more point regarding = and == (more flamage)
Message-ID: <1991Mar27.184833.7914@sq.sq.com>
Organization: SoftQuad Inc.
References: <13603@helios.TAMU.EDU> <1991Mar22.173037.26641@zoo.toronto.edu>
Date: Wed, 27 Mar 91 18:48:33 GMT
Lines: 37


>In article <13603@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes:
>>a)	while (*foo++ = *bar++)
>>b)	while ((*foo++ = *bar++) != 0)
>>
>>All I can say is, if you code in style (a) rather than style (b), don't
>>expect anyone reading your code to enjoy the experience.
>>
>>Henry, are you behind me on this one? ...

henry@zoo.toronto.edu (Henry Spencer) writes:

>Yes.  Deliberately using a construct that looks like a well-known and subtle
>programming error is a mistake.  Your successor, reading your code, should
>*never* have to ask himself "is this really right?"; if there is reason for
>doubt, either comment the code or change it.

I agree with the principle, but I disagree that it applies here.  The 
programmer must balance clarity-by-standard-idiom and clarity-by-explicitness.

From K&R1 (p. 101):
        ...
        while (*s++ = *t++)
        ...

"Although this may seem cryptic at first sight, the notational convenience
is considerable, and the idiom should be mastered, if for no other reason
than that you will see it frequently in C programs."

I find the idiomatic usage to be clearer, because it is easier to recognize.

Dak
-- 
David A. 'Dak' Keldsen of SoftQuad, Inc. email: dak@sq.com  phone: 416-963-8337
"Perhaps the most universally recognized tool for improving a professional 
programmer's productivity is C.  Not the C language...but the C additive, 
Caffeine." -- "COMPUTER LANGUAGE" April 1989 Product Wrap-Up Column by Ted Bahr
