Path: utzoo!attcan!uunet!lll-winken!ames!rex!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: comma operator:  keep away?
Message-ID: <833@twwells.uucp>
Date: 20 Apr 89 19:46:51 GMT
References: <10007@smoke.BRL.MIL> <498@lakart.UUCP> <10057@smoke.BRL.MIL> <628@gonzo.UUCP> <28831@ucbvax.BERKELEY.EDU> <828@twwells.uucp> <28847@ucbvax.BERKELEY.EDU>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 95
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <28847@ucbvax.BERKELEY.EDU> jas@ernie.Berkeley.EDU (Jim Shankland) writes:
: In article <828@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
: [again saying the comma operator is unclear, because it doesn't adequately
: separate two distinct operations; also, giving a couple of examples
: of slightly obscure code, with suggestions for improving readability.]
:
: I claim that when the operations are closely related, such as walking
: down two arrays in lockstep, the comma is adequate separation, and is
: arguably clearer -- and certainly more concise -- than a compound statement.

It depends. I often use various devices that break one or more
"rules".  E.g., the notion of splitting up separate operations might
well be thought to require as a rule that one put exactly one
operation per line. However, there are many cases where I don't do
this. One of my favorite examples is in a state machine, one which
looks like this:

	while (1) {
		switch (state) {
		case ST_FOO: act_foo();         state = ST_BAR;      continue;
		case ST_BAR: act_bar();         state = ST_BLETCH;   continue;'
		...
		case ST_DONE:                                           break;
		}
		break;
	}

I claim that, if it can be made clear in this way, that it is better
than the "put one thing on one line" approach. Certainly, I see it
that way.

: I was really trying to make a meta-point:  writing good, clear code
: is a lot more complicated than following a few simple rules.  Rules
: like, "Don't use the comma operator" are neither necessary nor sufficient
: to enforce good coding.  Effort spent inventing and enforcing such rules
: is better spent elsewhere.

I agree with all but the last sentence. There are two distinct
reasons:

    1) Having a set of default rules means that one doesn't have to
       spend lots of time re-inventing the wheel. One just writes the
       code according to the standard and, only when that appears
       inadequate, does one have to spend the time to design the
       appropriate layout of your text.

    2) Having a set of default rules also results in consistency in
       the final product. This consistency is important in that it
       makes maintenance easier and more reliable. Since there are
       many essentially arbitrary choices to make in code layout, if
       there were no standards, there would be many different ways of
       doing exactly the same things, resulting in more difficult to
       understand code.

I wrote a coding standard document for Proximity; here is its
introduction:

	This document contains a description of Proximity's C coding
	conventions and practices.  It describes rules for naming
	files and symbols, and outlines the format of source and
	include files.  It also discusses the use of Proxlib and the
	standard C library routines.  The benefits of these coding
	practices are threefold: the code is (1) more easily
	understandable, (2) more easily ported between systems, an
	important feature in Proximity products, and (3) more likely
	to work the first time and be free of hidden bugs.

	These rules should be followed in most code, but unusual
	situations may require unusual code. When breaking these
	rules, unless it is obvious from the context, you must include
	a comment stating why you broke them. This reason must be
	equivalent to ``Something bad will happen if I follow the
	rule'' rather than ``Something good will happen if I break the
	rule''. Thus, if you have a piece of code whose fast
	execution is essential to the quality of the product in which
	it is embedded, it would be proper to include a rule-violating
	hack. If, on the other hand, you have a neat trick which would
	make the program faster or smaller, when such is unnecessary,
	but which would break one of these rules or which would make
	the program unclear: DON'T DO IT!

	There are situations when it would be a good idea to modify
	some of these rules. If you run into one of these, discuss it
	with your project leader (or the head of the software
	department if you are the project leader). Then, assuming you
	can agree on the modification, go ahead and use your modified
	rule, but until you have had this document updated, comment
	your use. Also, tell the person responsible for this document
	about the rule change.

---
Bill                            { uunet | novavax } !twwells!bill
(BTW, I'm may be looking for a new job sometime in the next few
months.  If you know of a good one where I can be based in South
Florida do send me e-mail.)