more questions about efficient C code

[Roy Smith]

I said:
> > [...] the idiom is so well ingrained that I don't think twice about it.

DHowell.ES at Xerox.ARPA (Dan) responded:
> Don't think too much, it could be dangerous :-)

I try not to, it's too much work. :-)

> Idioms which are believed to be more efficient (sometimes mistakenly)
> should be given up in favor of constructs which are common to most
> programming languages. [...] making it understandable to all who are
> involved with a project

	I can't argue with that.  I use "if ((fd = fopen(...)) == NULL)"
not because it runs faster but because I think it makes the program
easier to understand.  We clearly have the same goal; making like easier
on people who have to read our code later on, even if it costs a bit in
execution.  We just disagree on how to reach that goal.

	I also am one of those people who sneer at complex code.  It
just so happens, however, that the 2 particular idioms I have seen
attacked recently (testing and assigning the value of a function at the
same time, and using "i++" instead of "i = i + 1") are among the few that
are on my "so ingrained that I don't think twice" list.  Obviously you
have a different definition for "complex idiom" than I do.  Fair enough.

	I do disagree with your point about using only those features of
C which are in common with other programming languages.  I'm not about to
give up structures and pointers just because FORTRAN doesn't have them.
Nor am I going to do without the conditional, boolean, or various
assignment operators.  They're part of C so why shouldn't I use (not
abuse) them?  Stuff like "i += xtab[foo++->bar[flag?baz1:baz2]]--" is
wantonly confusing; "i += foo->bar" is not.

	More important than what idioms you use is how (or if!) you
comment the code.  How many times have you tried to read 10 pages of
dense code without any useful comments?  Isn't commenting something they
teach in "Intro to Computers and Programming 101"?  So why don't people
do it?  I can deal with figuring out the gritty details of what a certain
idiom means as long as the author gives me a clue as to what is going on.

	It would be nice if the code was *both* simple and commented.
Force to choice one or the other, I'll take the comments any day.  With a
roadmap, I can usually find my way through the convoluted code -- it's
not so easy the other way around.
-- 
allegra!phri!roy (Roy Smith)
System Administrator, Public Health Research Institute