On Oct 2, 2006, at 3:54 PM, Nick Kew wrote:
On Monday 02 October 2006 23:31, Roy T. Fielding wrote:
We can avoid this by adopting an alternative coding style
that doesn't rely on confusing parentheses:
if (rv = do_something(args), rv == APR_SUCCESS)
Which nobody uses because it is so weird and unusual (speaking as
a perl
programmer who uses even more weird and unusual syntax all the time).
Not a Lisp programmer, I take it? (lisp is full of comma-lists)
I often use them in C, and have done since nineteeneightysomething.
Lisp is a fine language. Very useful for inducing blindness.
I just don't use it when I want to write readable C code, for the
same reason I don't use perl-style shortcuts (which actually originated
in C, sh, and awk, but are rarely used now in C).
It wouldn't surprise me at all to find that it doesn't even
compile with
some of the older C compilers, though I haven't tested it.
It's been clearly defined by ANSI C for as long as ANSI C has existed.
I'm pretty sure it was K&R before that, too.
Yes, it was, but is not commonly used in practice aside from within
declaration lists and for-loop increments. Personally, I think it is
because a comma is too difficult to see on a screen, but it may also
be because a parenthesized list of expressions looks just like a list
of function call parameters. *shrug*
In any case, I prefer the style of C code that more directly reflects
the underlying assembly, even if an optimizing compiler would produce
the same assembler for both. It is just natural to read "use the result
of this save operation for the test", as opposed to "save the result of
the operation, discard it, read it back into memory and then test".
YMMV. I don't think that commas are any less error-prone than parens.
....Roy
