Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!ulysses!andante!alice!ark
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: One more point regarding = and == (more flamage)
Message-ID: <20107@alice.att.com>
Date: 23 Mar 91 19:01:54 GMT
References: <13603@helios.TAMU.EDU> <3182@inews.intel.com>
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 32

In article <3182@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes:

> 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.

Not everyone agrees that comments should explain what code does
on a line-by-line level.  The trouble is that if a comment restates
what an obvious piece of code does, then it's just clutter -- and
if it says something different from the code then something is
seriously wrong.

People bring me a lot of broken programs to help fix.  The first
thing I do when looking at such a program is to cover up the
comments and insist that the author not attempt to explain the
program to me.  All too often the bug has been that the code
misstated the author's intent, although that intent was correctly
stated in the comments.

Stragetic comments are extremely important: ``this section ensures
that database X reflects the changes made to database Y.''  Tactical
comments, however, are sometimes of negative worth.

As to the original question, I stand by the recommendation I
made in `C Traps and Pitfalls:' if you have an assignment as
the top-level operator in a test, such as if(a=b), rewriting it
as if((a=b)!=0) will make your intentions obvious in a way that
the original never will.
-- 
				--Andrew Koenig
				  ark@europa.att.com