One more point regarding = and == (more flamage)
Jody Hagins
hagins at gamecock.rtp.dg.com
Sat Mar 23 05:52:00 AEST 1991
In article <3182 at inews.intel.com>, bhoughto at pima.intel.com (Blair P. Houghton) writes:
|> In article <13603 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
|> >It's this: There is no way when you see the code-fragment
|> >a) while (*foo++ = *bar++)
|> >to tell whether a copy of data in strcpy fashion is intended, or whether
|> >this should have been a strcmp-like loop:
|> > while (*foo++ == *bar++)
|> >the first instance is rendered UNAMBIGUOUS by the addition:
|> >b) while ((*foo++ = *bar++) != 0)
|>
|> Or by the additions:
|>
|> /* copy bytes till end of string */
|> while (*foo++ = *bar++)
|>
|> /* compare bytes till there's a difference */
|> while (*foo++ == *bar++)
|>
|> /* mommy: please hold my hand */
|> while ((*foo++ = *bar++) != 0)
|>
|> Basically, if you're worth the meager pittance they direct-deposit
|> into your debt with the Company Store, the comments will have
|> existed long before you wrote the code. Put those in, and make
|> them accurate, and it doesn't matter how much the code obfuscates.
|>
|> It's called top-down design, and involves _thinking_ before
|> you start making mistakes.
You know, I used to think this way too, while I was still an amateur.
"If you're worth the meager pittance they direct-deposit
into your debt with the Company Store" then you will not leave a
job half-done. You will complete it by adding to the documentation
clear, unambiguous code.
|>
|> --Blair
|> "Back to basics."
|>
-Jody
Jody Hagins
hagins at gamecock.rtp.dg.com
Data General Corp.
62 Alexander Dr.
RTP, N.C. 27709
(919) 248-6035
Nothing I ever say reflects the opinions of DGC.
More information about the Comp.lang.c
mailing list