C programming style

[Frank Adams]

In article <1710 at reed.UUCP> alexis at reed.UUCP (Alexis Dimitriadis) writes:
>> The use of i++ when i+=1 will do is certainly an abomination!  I personally
>> always use i+=1 when i just want to increment i but an not going to use
>> its value in that expression.  For instance
>> 
>> 	for(i = 0; i < DIM; i += 1)
>> 
>> People ask me WHY?  As it noted above everyone just uses i++.
>
>  I realize comments like the above are coming from people who do not
>claim long experience with C, but why all the excitement?

This is, in and of itself, a minor point.  The issue of readable code --
what it is and how important it is -- is not.  This is a minor battleground
of that larger discussion.

>  The meaning of
>
>	foo++;
>
>in a statement by itself (the context in which increment operators were 
>attacked) should be absolutely clear to anyone who knows what `++' does.
>Years of experience with kernel code are NOT required.  `foo++;' is also
>terser than `foo += 1;' (or foo = foo + 1; !!!), and it's at least as
>unambiguous.  The only blemish is, it doesn't _look_ like Pascal
>or FORTRAN.

We disagree here.  I think "foo += 1" is *significantly* more readable
than "foo++".  It is *insignificantly* less terse.  Both are, of course,
*perfectly* unambiguous, since they are specified by the C language
specification. :-)

However, I think "foo += 1" is better than "foo = foo + 1", because in
complex cases, it is both significantly terser, and significantly easier
to read.  Consider "(*foo)[bar]->shoe.shine += 1" versus
"(*foo)[bar]->shoe.shine = (*foo)[bar]->shoe.shine + 1".  Besides the
extra length, one must look closely to see that this is an increment,
and not, say, "(*foo)[bar]->shoe.shine = (*foo)[bar]->boot.shine + 1".
By contrast, "(*foo)[bar]->shoe.shine++" offers essentially nothing.

In other words, idioms are useful if they provide a significant improvement
in terseness, but not for a tiny improvement.