Write int as a 4 byte big-endian to file.

[Ike Naar]

[about

bytes = what % 256, what /= 256;

]

Clever people do not write code like that. Clever people *can* write
code like that, but are clever enough not to, because they understand
maintainance burdens, and why code clarity beats code cleverness in
99.9999% of cases.

There can be a good reason to write code like that.
Suppose we have variables x and y that represent the position
of a bishop on a chess board. The piece is currently on
a black square, and this is an invariant according to the rules
of the game. No legal move can put it on a white square.
Now we move it from (x, y) (black square) to (x+3, y-3) (black square).

It could be written like this:

/* initial: black square */
x = x+3;
/* intermediate: white square */
y = y-3;
/* final: black square */

but the intermediate state violates the invariant and that's ugly.
It would be cleaner to write it like this (using Python-like multiple
assignment):

/* initial: black square */
x, y = x+3, y-3;
/* final: black square */

and avoid the invalid intermediate state.
Of course C does not have multiple assignment, but this comes close:

/* initial: black square */
x = x+3, y = y-3;
/* final: black square */

I think here the use of a comma expression leads to somewhat cleaner
code: the fact that it's a single statement shows the intention
to make one legal move, instead of two illegal moves that combine
into a legal move.

 

[Ben Bacarisse]

Clever people do not write code like that. Clever people *can* write
code like that, but are clever enough not to, because they understand
maintainance burdens, and why code clarity beats code cleverness in
99.9999% of cases.

I fully agree about clarity, but how unclear was the code and in what
way? I don't like the idea of avoiding parts of the language because
some future reader might not might not know it. For one thing, where do
you draw the line? Who decides what's generally well understood? But
my real objection is that the lack of clarity is superficial -- a quick
look on the web, or a check in a book and everything becomes clear again.

When I was, however briefly, doing this sort of maintenance, I never
minded that sort of "clever" code. Seeing a neat way to write something
made a dull job a little more interesting. I really don't ever recall
making a mistake because of a syntactic misunderstanding, nor do recall
being significantly impeded by such a thing.

All of the hard maintenance problems I recall came from trying to
understand the dynamic behaviour of a program. The most obvious example
in C is whether allocated memory is used after it's lifetime has ended,
but there are lots of other. The worst I ever saw was an old Unix sort
utility which passed pointers around without the proper conversions. It
was almost impossible to tell if the pointer you had at some point was
really a char pointer or a struct pointer and, because this was a
word-addressed machine, that mattered. It took weeks to get it running
and I very much doubt I got all the bugs out even then. I would have
happily traded a thousand uses of the most obscure C syntax for a
clearer and better organised program.

On the use of the comma operator, I agree with Tim that it's useful when
the purpose of the expressions are closely related. I use it,
for example, when a function "returns" more than one thing:

return *reason = ZERO_DIVIDE, FAIL;

 

[Tim Rentsch]

@alumni.caltech.edu> wrote:

for( i = 3; i >= 0; i-- ) bytes = what % 256, what /= 256;

What ??? Did you do this with a comma operator just to make it hard
to read?

No, I used a comma operator because I think of the two assignments
as a single conceptual unit (extract the low order bits and shift
those bits out of the word being worked on), so it seems natural
to express that conceptual unit as a single statement.

If you worked under me I'd make you re-write that code properly.
"Clever" people tend to write code that holds up less under the test
of time.

If you worked under me you would learn that different
groups have rather different ideas about what constitutes
good or readable coding style, and it's better not to
be so dogmatic about it. But then neither one of those
hypotheticals holds, does it?

 

[Tim Rentsch]

Clever people do not write code like that. Clever people *can* write
code like that, but are clever enough not to, because they understand
maintainance burdens, and why code clarity beats code cleverness in
99.9999% of cases.

The case in question was purely an issue of coding style. Some
people (I happen to be one of them) think the particular style
used improves clarity, not reduces it. If someone prefers a
different style, I'm okay with that. But I wouldn't call it
"clever" or "not clever", just a different style.