C programming style
DHowe...@xerox.arpa
programmer, I am an experienced programmer. These replies are based on
my limited knowledge of C, but I believe they are applicable to all
programming languages in one way or another.
>Ok, I give up! Tell me how is it easier to find out what fp is when it
>is on a single line. You find out what fp is by printing out its
value.
>You might also explain why someone would NOT want to reference fp again
>[In other words, why would you open a file for reading if you didn't
>want to read from it?]
If I am using a C interpreter, I could find out what fp is by printing
out its value. However, when I am looking at the program on paper, and
I see the variable "fp" being used, I want to find out what fp is
representing. If I see the statement "fp = fopen("foo", "r");", where
fp is at the beginning of a line then I know that fp is referring to the
file "foo". But if I have to look for it in an if statement, then it's
that much harder to understand. Sure I can understand it, and
"experienced C programmers" can understand it, but is everyone you're
working with an "experienced C programmer"?
>Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to
me,
>especially (as someone else has pointed out) when 'i' is a longish
expression.
Maybe "i++" is clearer to you, but do you only write programs for
yourself? To me "i++" is the kind of statement typical of an APL-type
language, not a language that is supposed to be structured and easy to
understand. "i++" could mean something else in another language. But
almost all high level languages (even APL) use some form of "i = i + 1"
to increment a variable. If I want to distinguish between incrementing
and adding, then I would define a procedure such as "increment(i)",
which can be immediately understood.
If you completely understand the problem you're solving, and you are
working with no one but yourself, by all means use whatever cryptic
language idioms you want. But if you are writing for someone else,
remember that the person who understands the *problem* may not
understand the programming language. Do whatever you like as long as
you can explain it to the person who knows what he/she wants done.
Progams should be as language-independent as possible. It shouldn't
matter whether the program is in C, Pascal, Ada, or even the dreaded
APL, but that it can be understood by *anyone* who needs to look at the
program. If you limit that *anyone* to "experienced C programmers",
you're limiting the possibilities of that program.
Dan /* comments are of course welcome */
Tom Kessler
>yourself? To me "i++" is the kind of statement typical of an APL-type
>language, not a language that is supposed to be structured and easy to
>understand. "i++" could mean something else in another language. But
>almost all high level languages (even APL) use some form of "i = i + 1"
>to increment a variable. If I want to distinguish between incrementing
>and adding, then I would define a procedure such as "increment(i)",
>which can be immediately understood.
i don't know about you but my c compiler generates 3 fewer instructions
and does all of the adding in registers when i user i++ instead of i = i + 1.
--
--------------------------
Tom Kessler {allegra |seismo }!rochester!ur-laser!tomk
Laboratory for Laser Energetics Phone: (716)- 275 - 5101
250 East River Road
Rochester, New York 14623
pre...@ccvaxa.uucp
> > Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to
> > me, especially (as someone else has pointed out) when 'i' is a longish
> > expression.
>
> Maybe "i++" is clearer to you, but do you only write programs for
> yourself? To me "i++" is the kind of statement typical of an APL-type
> language, not a language that is supposed to be structured and easy to
> understand. "i++" could mean something else in another language. But
> almost all high level languages (even APL) use some form of "i = i + 1"
> to increment a variable. If I want to distinguish between incrementing
> and adding, then I would define a procedure such as "increment(i)",
> which can be immediately understood.
I try not to write "i++" as a statement, though I use it in for
statements, of course. But I NEVER write "i = i + 1", always using
the form "i += 1", which conveys the obvious information that this is
an increment rather than a generic assignment. If the language provides
a way for you to tell the compiler more about what you're doing, use it.
I also would claim that a form specifically indicating that you're
incrementing a value is clearer to the reader, especially the relatively
inexperienced reader. The form "i = i + 1" is a text-book example of
a concept difficult for beginners to understand.
----------
> Progams should be as language-independent as possible. It shouldn't
> matter whether the program is in C, Pascal, Ada, or even the dreaded
> APL, but that it can be understood by *anyone* who needs to look at the
> program. If you limit that *anyone* to "experienced C programmers",
> you're limiting the possibilities of that program.
I submit that the phrase "least common denominator," applied to
anything but its mathematical meaning, is pejorative. Society respects
those who use tools WELL. That usually means idiomatically. No, I don't
believe in performing professional tasks with undue attention to the
needs of unprofessional successors, except where that is a specific
goal (writing, for instance, code intended to be modified by end users).
It is VITAL to make code clear and understandable, but it is not
necessary to assume that the person reading it doesn't know the
language.
Some people seem to think that idioms exist to obscure meaning. Nothing
could be further from the truth. Idioms provide insight into meaning,
to those who know the language. Idioms arise because they are natural
ways to express something: a person does something in a way that seems
natural and others, seeing that expression and finding it pleasing,
adopt it. Idioms help the reader figure out what is going on.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
Ron Natalie <ron>
> >yourself? To me "i++" is the kind of statement typical of an APL-type
> >language, not a language that is supposed to be structured and easy to
> >understand.
> and does all of the adding in registers when i user i++ instead of i = i + 1.
> --
who were the target group the language was written for. It's a very obvious
carry over from index mode operations that most assemblers use.
-Ron
mdavi...@crash.arpa
code that looks good or code that runs well.
Morgan Davis -- {ihnp4, cbosgd, sdcsvax, noscvax}!crash!mdavis
crash!mdavis@ucsd -- or -- crash!mdavis@nosc
Frank Adams
In article <11...@brl-tgr.ARPA> DHowe...@Xerox.ARPA writes:
>Let me start out by saying that while I am not an experienced C
>programmer, I am an experienced programmer. These replies are based on
>my limited knowledge of C, but I believe they are applicable to all
>programming languages in one way or another.
I am an experienced programmer. I have been writing C for about four
months now.
>Maybe "i++" is clearer to you, but do you only write programs for
>yourself? To me "i++" is the kind of statement typical of an APL-type
>language, not a language that is supposed to be structured and easy to
>understand. "i++" could mean something else in another language. But
>almost all high level languages (even APL) use some form of "i = i + 1"
>to increment a variable. If I want to distinguish between incrementing
>and adding, then I would define a procedure such as "increment(i)",
>which can be immediately understood.
I agree that "i++" is an abomination. (I do use it, however, to be
consistent with the rest of the code I work with.) Actually, C has
a third way to represent this operation: "i += 1". Personally, I
think this is the superior notation. It is concise, yet easy enough
for a person unfamiliar with the language to interpret.
Incidently, "i = i + 1" is not all that obvious, either. Many people's
response, on seeing such an expression for the first time, is "impossible.
'i' can't equal 'i + 1'.".
Ned Robie
> matter whether the program is in C, Pascal, Ada, or even the dreaded
> APL, but that it can be understood by *anyone* who needs to look at the
> program. If you limit that *anyone* to "experienced C programmers",
> you're limiting the possibilities of that program.
>
> Dan /* comments are of course welcome */
I disagree. If programs were written to be as "language-independent" as
possible, what kind of languages would we be using??? Wouldn't this have
the net effect of significantly slowing the evolution of computer language?
I mainly program in C and Pascal, but I'm very glad that I had the opportunity
to learn and use APL. It is a unique language with many good ideas. It is
not perfect, but then no language is. It is not effective in all applications;
no language that I'm aware of is. But I found it to be a refreshing, exciting,
and fun(!) way to solve problems. Best of all, it made me a better programmer.
The short-term benefits of *everyone* programming in compliance with the
current popular semantic model are appealing, but the long-term results
would be to retard the research and development of other forms of human/
computer communication. In light of the fact that many of today's problems
cannot be adequately expressed to a machine, this would be a grave mistake.
-- Ned Robie
Karl Braun
> yourself? To me "i++" is the kind of statement typical of an APL-type
> language, not a language that is supposed to be structured and easy to
> understand. "i++" could mean something else in another language.
> and adding, then I would define a procedure such as "increment(i)",
> which can be immediately understood.
var++ or ++var is a basic primitive of C. If you don't immediately comprehend
what var++ means, then you don't know C (as in, haven't even looked at the
manual). It is exactly equivelant to a procedure 'increment(var)'.
Yes, maintenance costs more than original program development and it's costs
should be weighed against development costs, but, as I think most C programmers
would agree, this particular statement is so fundemental to the language that
is kind of silly not to use it. The comment regarding the effeciency of the
produced code is probably applicable to most compilers, but academically, any
reasonable optimizer should optimize 'i = i + 1' to equivelant code.
I guess the main point is this: if you don't understand 'var++' then you
probably are not quite ready to be upgrading C code.
Frank Adams
In article <11...@brl-tgr.ARPA> r...@brl-tgr.ARPA (Ron Natalie <ron>) writes:
> It's (i++) a very obvious
>carry over from index mode operations that most assemblers use.
>
>-Ron
Most assemblers FOR WHAT MACHINE? Never mind answering, I know. Try
broadening your horizons a bit.
Kim Christian Madsen
>
>I am an experienced programmer. I have been writing C for about four
>months now.
Does that make you a experienced C programmer ???? (-;
>I agree that "i++" is an abomination. (I do use it, however, to be
>consistent with the rest of the code I work with.) Actually, C has
>a third way to represent this operation: "i += 1". Personally, I
>think this is the superior notation. It is concise, yet easy enough
>for a person unfamiliar with the language to interpret.
The main advantage of the ++ or -- notation in C is that you can construct
a loop and control the increment-variable [let's call it ``i'' for the old
Fortran days] by means of ++i or i++ in order to assure that ``i'' has the
proper value after the loop -- instead of +/- 1 which is the default in many
other languages as Pascal/Fortran/Basic etc...
--K...@diku.uucp
Jerry Aguirre
> programmer, I am an experienced programmer. These replies are based on
> my limited knowledge of C, but I believe they are applicable to all
> programming languages in one way or another.
.
> >Typing has nothing to do with it, "i++" is clearer than "i = i + 1" to
> >me,
.
> to increment a variable. If I want to distinguish between incrementing
> and adding, then I would define a procedure such as "increment(i)",
> which can be immediately understood.
Wants to define a "procedure" such as "increment(i)", claims to understand
C, obviously doesn't! Could be done as a macro but never as a procedure.
I have seen several projects coded in the "make it look like algol" style
of programming. They define BEGIN to be { and END to be ;}, etc. It always
seems to cause more trouble in the end than it saved. By the time they
finished the project they are usually familiar enough with the language
that they no longer need these crutches. Experienced C programmers get
frustrated trying to follow the code because there is always this extra
level of indirection that has to be verified as correct. I have at
times refused to help users with "C problems" because figuring out
whether the syntax is correct requires reading a 300 line header file
that compleatly redefines the language.
No, increment(i) is not clearer than i++; If I want to understand what
i++ means I only have to check the language spec. Once I understand it
I know more about the C language.
If I come across an increment(i) then I am left in the dark. Is this
built into the language, a "procedure" defined later in the code, in an
included file, from a library? Is it defined correctly? Does it
handle floats, longs, and ints? How can it change "i" when C has call
by value?
And after I figure out what increment(i) does then I have learned how
one person coded one program. When I work on someone elses code I have
to start all over and learn what "next(i)" does.
Writting clear code is like driving. It doesn't matter whether you
drive on the left or right side of the road. What matters is that you
drive on the side people expect you to.
If you want ease of maintenance then concentrate on USEFUL comments. My
favorate non-comment is:
int debug; /* true if debugging is enabled */
or the ever popular:
i++; /* increment i */
Usually followed by a 3 page procedure with a cryptic name and no
comments. I mean is it really hard to figure out what the variable
debug is used for? I would really rather have a few lines at the top
of each procedure telling what it does and what the arguments are. It
is usually easy to follow the code if you know why the procedure was
called. It's trying to follow the code when you don't know what it was
called for or what its inputs are that is hard.
Languages don't write bad code, people do.
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry
Michael J. Tuciarone
This whole discussion has become become silly enough without it
degenerating into flames concerning "professionalism" and so
forth. If you're reading this, someone is sufficiently convinced
of your qualifications that they gave you a computer account. (Or
at least you know enough not to break things.) If you can *write*
to the net, you are able to wade through Unix [tm blah blah] do-
cumentation and operate the system and programs...de facto, not a
rank amateur.
Regardless, this is not net.flame. Let's try to have a little
professional courtesy and keep it clean, ok?
And about "style" and "idiom"...Computer languages are generally
designed to either fit a particular application (e.g. C, Forth,
Ada) or demonstrate a principle (e.g., Pascal, APL, Lisp). Easy,
easy, flames off. The utility of a language is inseparable from
its features and syntax, which in turn are wholly dependent on
the underlying design concept. With respect to C, the very first
sentence in "The C Programmer's Manual" (you all *do* have a copy
of K&R, don't you?) reads, "C is a general-purpose programming
language which features economy of expression, modern control
flow and data structures, and a rich set of operators."
Increment and decrement operators, conditional expressions, and
returned values from assignment statements are not just a part of
C, they are accepted and preferred usage. One of the great vir-
tues of C is its (potential) brevity and elegance; "economy of
expression" is a design goal of the language! The conscientious
programmer, like any skilled craftsman, will eschew opaque or in-
comprehensible constructions. But idioms such as:
char buf[80], *cp = buf;
while ( (*cp++ = getchar()) != '0 )
;
are common, short, and understandable at a glance to the program-
mer. Phrases like the above are the heart of C. I moved to C from
Pascal and never looked back, if only because I could finally fit
the whole function on one screen.
There is, in any language, a certain overhead involved in learn-
ing the language and its idioms. But all living languages will
develop their own shorthand and common expressions. Good program-
mers, like users of *any* language, will note the expressions in
common use, and further those that are elegant, simple, and ex-
pressive while avoiding the unclear and confusing.
C may never approach Pascal for sheer readability, but the trade-
off made in favor of brevity and richness of expression seems
well worth the small extra effort invested in learning to speak
the language well.
Hoping you're still awake,
Mike Tuciarone
...{hplabs, ucbvax}!atd!tooch@avsdS
Audio/Video Systems Division
Ampex Corporation
"One of the [Allied-]Signal Companies"
Eugene D. Brooks III
> consistent with the rest of the code I work with.) Actually, C has
> a third way to represent this operation: "i += 1". Personally, I
> think this is the superior notation. It is concise, yet easy enough
> for a person unfamiliar with the language to interpret.
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 reserve the ++ and -- operators for when I an really doing something
special, incrementing or decrementing and using the value that existed BEFORE
the operation. The occurence of ++ or -- in a program is a red flag telling the
reader that something very special is happening.
If you use ++ or -- when you simply want to decrement or increment then the
cases when its important to note the ordering of the operation and the returned
value of the expression get lost in the forest of ++s and --s an you get left
with buggy code. Its the very much the crying wolf syndrome!
Duncan R. Gibson
Re: i++ and i = i + 1
As an aside, I remember being taught AlgolW as a student, where i := i + 1
and i := 1 + i were equvalent statements, and incremented i. I then moved to
PL360 (yuk!) for a while where i := i + 1 inrements i, and i := 1 + i sets i
to 2.
This caught a lot of students out, especially as the two languages can be
made to look similar. At least i++ and ++i are *obvious* if you have read
*any* introductory text to C.
Ken Arnold%CGL
>The comment regarding the effeciency of the
>produced code is probably applicable to most compilers, but academically, any
>reasonable optimizer should optimize 'i = i + 1' to equivelant code.
(I have extracted this out of an article I otherwise agreed with
completely, because this is not true, as will be elucidated below).
This is quite true for such simple expressions as
i = i + 1;
but not true at all for such things as
a[f()] = a[f()] + 1;
which cannot be reduced to
a[f()]++;
Which is another reason why this can't be done.
Another thing which ++ saves is typos. If you use
i = i + 1;
you must retype "i". This is fine when "i" is simple, but if it is
a complex variable expression, you could get two legal expressions which
are different instead of the same, and then not get the same effect
(not to mention the efficiency).
All in all, if "increment(i)" is more clear than "i++", you don't know
C. Since ++ means "increment", nothing could be clearer. Or would you
prefer "and", "or", "plus", "minus", etc.? Urg.
Ken Arnold
Michael J. Tuciarone
The line in my previous posting <7...@avsdS.UUCP> which read
> while ( (*cp++ = getchar()) != '0 )
> ;
and was supposed to be a glorious example of good C style
that would, shining before us like the Holy Grail, lead us
to the Promised Land of Good Coding Practices...
got screwed up.
It was *supposed* to read
while ( (*cp++ = getchar()) != '\n' )
; ^^^
Thus does the Master, whilst enlightening the Novices, fall flat
upon his Ass. Flames will be received in long-suffering silence.
Mike Tuciarone
...{hplabs, decvax}!atd!tooch@avsdS
And hey...hey!...HEYY!!!
...Let's be *careful* out there.
Frank Adams
In article <5...@oliveb.UUCP> je...@oliveb.UUCP (Jerry Aguirre) writes:
>If you want ease of maintenance then concentrate on USEFUL comments. My
>favorate non-comment is:
> int debug; /* true if debugging is enabled */
>or the ever popular:
> i++; /* increment i */
>
>Usually followed by a 3 page procedure with a cryptic name and no
>comments. I mean is it really hard to figure out what the variable
>debug is used for? I would really rather have a few lines at the top
>of each procedure telling what it does and what the arguments are. It
>is usually easy to follow the code if you know why the procedure was
>called. It's trying to follow the code when you don't know what it was
>called for or what its inputs are that is hard.
Broadly speaking, I agree with this. But you should go a step further,
(especially for a 3+ page procedure) and put a comment at the top of
each logical section of the code. This makes it easier to read the code
and figure out what the program does. A comment on each line doesn't
(much) do this, because one can as easily read the code as the comments.
Only obscure statements need comments, which is why one puts a comment
on every line in assembler code. (! :-)
>Languages don't write bad code, people do.
Yes, but some languages make it easy to write good code, and hard to write
bad code, while others do the opposite.
> Jerry Aguirre @ Olivetti ATC
>{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry
Frank Adams
Andrew Koenig
> and i := 1 + i were equvalent statements, and incremented i. I then moved to
> PL360 (yuk!) for a while where i := i + 1 inrements i, and i := 1 + i sets i
> to 2.
PL360 was unusual in that there was no operator precedence: all operators
(including assignment!) grouped to the left. Thus i := 1 + i meant
(1) i := 1; (2) i := i + i;
Incidentally, it was possible in later versions of PL360 to increment i
by simply writing
i + 1;
the idea being that writing an expression without an assignment
would use the first operand as its implicit destination.
And what about the =: operator?
i + 1 =: j shl 2;
means: add 1 to i, put the result in j; now shift i left 2 bits.
Steven List
omission: ++i (and it's relatives)! The original poster (at least I
think it was the original) suggests a function (or macro)
"increment(i)". The function/macro approach does not deal with the
sequence of events. The nominal case of incrementing a variable in a
simple expression
i++;
is trivial. How about in a loop:
char buf[80];
char *cp = buf;
/* always leave the first character alone */
while (*(++cp));
searching for the first NUL in a string. This is not necessarily a
useful example, but does demonstrate the case. How do you use the
function/macro? It requires more statements and is not as clear, to me.
I've been told that I write/understand cryptic C. This is not cryptic
to me. It is concise and clear. What's the objection to using the
language as designed? Why NOT use features?
--
***
* Steven List @ Benetics Corporation, Mt. View, CA
* Just part of the stock at "Uncle Bene's Farm"
* {cdp,greipa,idi,oliveb,sun,tolerant}!bene!luke!itkin
***
Ken Arnold%CGL
>C may never approach Pascal for sheer readability, but the trade-
>off made in favor of brevity and richness of expression seems
>well worth the small extra effort invested in learning to speak
>the language well.
Mike makes several excellent points in this article (including an
appeal to professional courtesy from all of us professed
professionals), but I think he is being a bit oversimple here.
Readability is not a boolean value, but a vague factor with many
variables. Some of these are language dependent (I always find APL
nearly impossible to read, for example; others may not, so maybe this
is "programmer+language dependent"). Others are programmer dependent.
C is very readable. To me, it is more readable than PASCAL, because
its bandwidth of communication is higher, i.e., it uses nearly the full
ASCII set of characters instead of words. I find it easier to scan C
code than PASCAL code because "and", "begin", "end", etc., have to be
read to distinguish them from variables, whereas &&, {, }, etc. are
easy to tell from variables. The "richness of expression" of C
contributes to its readability WHEN you know the language. When you
don't, it hurts.
This doesn't bother me. The fact that I don't understand how my car
engine works never stopped me from driving it. It would be nice if I
did understand all the techonology I use so that I can fix it when it
doesn't work, but I don't. So I don't understand why people expect
programs to be understandable to everyone. They tried that with COBOL,
and what they ended up with was a still unreadable language that nobody
wanted to program in (not that it stopped the bosses from wanting them
to).
Ken Arnold
Alexis Dimitriadis
>
> 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? 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.
Now about things like
while (*++ptr);
It _does_ take effort to decipher just what they do, even if you know
the language. _That_ is unclear, and so are things like
if (foo = scanf("%f", &num) != 1 || num > 0)
fubar();
comment(foo);
that is, complex expressions without any parentheses to indicate what
is actually happening, or (all too often), if the "professional"
who wrote it intended it to happen. (There is a parenthesis error in our
ctime(), for example). This kind of thing is unclear regardless of
familiarity with the language.
I do not agree that only "professionals" should use C, but there
is nothing wrong with using basic features of the language in a simple way.
I think it would be nice, in fact, if more people were familiar with
"structured" languages like C and Pascal. (I wish the teaching of BASIC
would be made into a Federal offense!) After all, the _big_ problems with
C readability arise from use of its facilities in an obscure
(e.g., unstructured) way, not from the choice of operators!
Alexis Dimitriadis
exit(errno ? (perror(argv[0]), errno) : 0);
/*NOTREACHED*/
--
_______________________________________________
As soon as I get a full time job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.
alexis @ reed
...teneron! \
...seismo!ihnp4! - tektronix! - reed.UUCP
...decvax! /
Walter Bright
>produced code is probably applicable to most compilers, but academically, any
Most Pascal and Fortran compilers will replace i=i+1 with i+=1 internally.
C compilers, however, usually don't bother because the i+=1 and ++i forms
are available, and the assumption is that they would have been used. These
comments also apply to all the op= forms in C.
Some C compiler trivia:
Since (i+=1) is exactly equivalent to (++i), most C compilers immediately
translate (++i) into (i+=1), and internally use the second one from then
on. Also, (i++) is usually internally translated to (i+=1) if the result
of the expression is not used. These kinds of conversions make life
easier for the code generator.
Frank Adams
In article <17...@reed.UUCP> ale...@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.