Use of expression values in C

[preece at ccvaxa.UUCP]

> If doing the operation is so much clearer, why do we bother with
> subroutines?  After all, to figure out what the subroutine does, you've
> got to look through its code, but if the operation were done inline,
> there would be no problem :-)
----------
Well, there's a qualitative difference between using a subroutine to
replace a number of lines of code to perform a complex operation and
using a macro with several arguments to replace a more straightforward
construction.

I don't use embedded assignments because they're more efficient (are
they?), I use them because they make sense.  The first time I saw them
(18 years ago in Dartmouth BASIC) I recognized them as superior chunking
agents.  Remember chunking?  Psychologists tell us that we build
separate concepts up into more complex chunks so that we can comprehend
more than seven (plus-or-minus two) concepts at a time.  Things like
embedded assignments and increment operators help [me, at least]
build up a larger logical operation than would be possible otherwise.
The ONLY thing I object to about them is that there ought to be a more
obvious distinction between the assignment and comparison operation
symbols.
----------
> Perhaps, the solution to all this would be a procedure.  Calling
> 'openfile(filename, &fileptr, "r")' gets 'fileptr' set appropriately.
> If the open fails a message goes to stderr and 'exit' is called.
----------
We all have our preferences.  You dislike embedded assignments,
I dislike procedures changing their arguments.

I'm currently working on a project that has a huge collection of macro
definitions.  Without them life would be impossible: they make it
possible to do things neatly and transparently.  They also make some
kinds of problems very hard to find, at which point it becomes
necessary to run cpp on the code and see what is really happening.
Defining macro expansions and procedures so that they behave in a
sensible, consistent, predictable fashion is very, very difficult.
----------
> But, for the record, I consider assignments in 'if' statements
> dangerous because I expect 'if' statements to only do tests.
----------
Chacun a son gout.  All that really matters are consistency and
clarity.  If you work within an orderly style and explain what
you're doing, your successors will figure it out.
----------
> Trying for micro-efficiencies at the cost of obscure code is
> the sign of an immature programmer or a poor typist.
----------
We just differ on what is obscure.  I think that the dense but
straightforward  "if ( (foo=fopen(filename,"r")) == NULL) { ... }"
IS clear and simple.  I think that hiding it in a macro or breaking
it into two lines makes it less clear and more obscure.  There's
nothing wrong with this kind of disagreement.  I wouldn't say
either approach indicates, by itself, immaturity or unprofessionalism.
----------
> Run a profiler on your programmer if you think it needs speeding up -
> you'll probably find something really gross that slipped by you while
> you were trying to construct an 'if' statement with three '++'s
> imbedded in it.
----------
This is the absolute truth.  If efficiency is the issue, always look
for big gains first.  Inefficiency is MUCH more likely to
come from a broken algorithm than from careless code.

On the other hand, DO go back over your 'finished' code and look to
see that you've been consistent.  The very best thing you can do for
future maintenance programmers is to make sure you always do the same
thing the same way.

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece