dg@lakart.UUCP (David Goodenough) (04/14/89)
From article <10007@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <626@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes: >>> x ^= z, y^= z; /* flip those that do */ > - x ^= z; /* flip those that do */ > - y^= z; > -If you don't see _why_ this is the right way, you'd better not work on a > -project with anyone but yourself. > > Hey, now, it's not all that clear cut. Conceptually the two > assignments should occur in parallel; for some people using , to > separate such assignments is the "natural" way to express that. In either case, the assignments happen one after the other. As far as I know, C has no equivalent to the BCPL mechanism: a,b := b,a Which is what we were trying to do in the first place :-) I would add that the comma operator has it's place, and there is nothing wrong with saying: #define swap(a, b) ((a) ^= (b), (b) ^= (a), (a) ^= (b)) except the ususal caveats about lvalues and side effects. Think what swap(i, getchar()) Would do :-) [Ouch] -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/17/89)
>From article <10007@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): >> Hey, now, it's not all that clear cut. Conceptually the two >> assignments should occur in parallel; for some people using , to >> separate such assignments is the "natural" way to express that. It never ceases to amaze me how people fail to read the words that I put a fair amount of thought into and instead try to explain to me how the C comma operator works. Please believe me when I tell you that I know how the comma operator works. Then go back and see if you can figure out what I was saying. Thanks.
daveb@gonzo.UUCP (Dave Brower) (04/18/89)
I posted a provocative note, the gist of which was that
if( cond )
e1, e2;
was rotten C programming practice for multiple person projects. Some
people think that is personal preference on my part. Of course I
disagree, and I'll attempt to explain why below.
My "red cape in front of a bull" chemistry produced this retort, which
I'll print and put on my "code from hell" board. Even though I program
exactly that way in /bin/sh, it is not good C for the same reasons the
comma code above makes me ralph.
"To make Dave Brower really barf, I've started writing my simple if
statements as: "condition && statement". Comes from LISP I suppose."
[Instant rebuttal: Everybody writes lisp that way, so it's OK lisp.
How does everybody write C?]
The issue is not absolute code correctness. I will cede that any of
these methods is functionally equivalent to a compiler. The issue is
human intelligibility, which is a different issue. How will people
other than the original author support and maintain this code months and
years after it is released?
I assert that 99 out of 100 competent C programmers write the
same piece of code as the braced, multiple statement sequence:
if( cond ) { /* brace placement left as religious discussion */
e1;
e2;
}
So, I claim 99 out of 100 competent C programmers reading this code
years from now are going to suffer cognitive dissonance on a "comma-ed"
construct when they come upon it. What does the author get from using a
comma? Internal ego strokes for demonstrating once again what a "hot
coder" can do to be obscure while still being correct. Does it enhance
the readability of the code? Not to anyone expecting braces, even the
author 6 months from now. So 99% of the programmers reading this code
will need to spend 5 extra seconds thinking about that line wondering
what is going on because it was not the obvious thing they have come to
expect.
If it is not obvious the program is not communicating its intent to the
human audience very well. That is not good programming, even if it is
"correct."
The comma operator is rarely used in practice, because the real C idiom
is to use braced statments. There are a few cases where it is
approriate, for(;;) loop setup and iteration and in macros that need to
evaluate to a particular value.
Only a raging egomaniac will go out of his way to obscure his code by
using a comma operator elsewhere, even if it "works just fine." Given a
choice between two constructs with equivalent semantics and performance,
the good programmer is going to pick the one more readily understood by
average people reading the code.
If you are working alone, go ahead to write that program that will make
the world believe that obscure feature X is the cat's meow. Just don't
do it in that module you are sharing with 99 other programmers, for
which you are receiving a professional's compensation.
Practically speaking,
-dB
--
"An expert is someone who's right 75% of the time"
{sun,mtxinu,amdahl,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucpjoe@gistdev.UUCP (04/19/89)
% Written 2:15 am Apr 18, 1989 by gonzo.UUCP!daveb in comp.lang.c > I posted a provocative note, the gist of which was that > > if( cond ) > e1, e2; > > was rotten C programming practice for multiple person projects. ...... > > if( cond ) { /* brace placement left as religious discussion */ > e1; > e2; > } > So, I claim 99 out of 100 competent C programmers reading this code > years from now are going to suffer cognitive dissonance on a "comma-ed" > construct when they come upon it. Gee, I must be the other guy, because that type of code can actually be more readable in certain cases. > What does the author get from using a comma? Glad you asked. :-) How about in a situation dealing with coordinates? I think that: if ( cond ) x = xvalue, y = yvalue; is far preferable to: if ( cond ) { x = xvalue; y = yvalue; } If the two operations being performed are logically related, I like seeing them on one line. I really can't see that it makes the code unreadable to do so. I guess if you want to complain about C programming practices, there are many that are far worse than placing two statements on a line with a comma between that obscure maintainability.