Xref: utzoo comp.unix.questions:12949 comp.lang.c:17733
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!rtech!gonzo!daveb
From: daveb@gonzo.UUCP (Dave Brower)
Newsgroups: comp.unix.questions,comp.lang.c
Subject: Re: Bit Switching - How? (really comma operator)
Summary: Raging Egos
Message-ID: <628@gonzo.UUCP>
Date: 18 Apr 89 07:15:29 GMT
References: <10007@smoke.BRL.MIL> <498@lakart.UUCP> <10057@smoke.BRL.MIL>
Reply-To: daveb@gonzo.UUCP (Dave Brower)
Organization: Gonzo Media Group
Lines: 71

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.uucp