One more point regarding = and == (more flamage)

[Jody Hagins]

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.