Michael S <
already5chosen@yahoo.com> writes:
On Tue, 06 May 2025 05:59:20 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
Michael S <already5chosen@yahoo.com> writes:
>
On Wed, 16 Apr 2025 14:09:44 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>
bart <bc@freeuk.com> writes:
>
On 15/04/2025 20:07, Scott Lurndal wrote:
>
>
Let's look at that C again:
>
for (int i = 1; i < 11; i += 1) # 15 tokens; C
>
for(i = 1; i++ <= 10;)
>
I'd reject this code during review.
Hopefully, you too.
>
I'm curious to know the basis for your reaction. What about the
code would prompt your judgment to reject it? Is it just a
specific reaction, or does it represent some more general pattern
(and if so then what more general pattern)?
>
First and foremost it was tongue-in-cheek reaction to the article
that Scott posted 2-3 minutes after the article that I was
reacting to.
I took the posting at face value.
At the next level, it is true that if I do detailed code review
(which I almost never do) I would indeed reject this code. The
first and sufficient reason is that the code looks superficially
similar to very common idiom, but significantly differs in
behavior. An additional reason is that post-increment operator is
generally harder to reason about than almost any other C operator,
esp. so when used as part of comparison, so, IMHO, readable code
should limit use of post-increment to very common idioms (or
altogether avoid it). The third reason, related to the first two
is that behavior of this loop is way too surprising.
I see your comments as saying a few different things. My intention
below is to give fair paraphrases; please voice an objection if you
feel that this was not done.
One: the given code syntactically resembles a common code pattern
but has quite different semantics.
Two: postfix ++ is harder to understand than other operators.
Three: the combination of postfix ++ and a comparison operator
is even harder to understand than its simpler uses.
Four: postfix ++ should never be used except in familiar and
commonly used patterns.
Five: the effect of the for() controlling statement is not what
most readers (selected from experienced developers) would expect.
Would you say that these statements above give a fair restatement
of your comments? Or have I missed or misrepresented something?
Taking the above points as fair restatements, here are my reactions.
Point one is never a reason to reject a given code fragment. If a
piece of code intends to express a particular semantics, but happens
to resemble a more common pattern that has different semantics, that
by itself is never reason to reject the code under consideration.
It's reasonable to say that a comment be given to alert a reader to
an unobvious difference, but not to reject the code outright.
Point two is true at least insofar as postfix ++ is more complicated
than simple arithmetic operators like + and *. The same could be
said of all operators with side-effects. Do you think postfix ++ is
more complicated than postfix --? Both postfix ++ and postfix --
appear in common and familiar patterns. I don't think the given
code fragment should be rejected solely for using a postfix ++.
Point three is certainly true, at least in comparison with using
postfix ++ by itself. But I don't see why you think using the
result with a comparison operator is more complicated than other
compound uses. Consider these code fragments, not too difficult
I think for most developers:
*lines++ = next_input_line();
while( i-- > 0 ) ...
I don't see either of these examples as being too different than the
condition 'i++ <= 10'. Is your only reason for rejecting the given
code is that you find it unfamiliar?
Point four seems to say explicitly what came up implicitly in point
three. I think a lot of people follow a similar rule, one not
necessarily restricted to postfix ++ or other less-used patterns.
As a guideline I think that's okay; as an inviolate rule I think
it's wrong. Developers should always write code in a way that they
feel best expresses their intentions, whether that way is an old
way or a new way. A second consideration is that, if code is only
ever written in old familiar ways, then newer and better ways will
never be discovered. Taking a conservative stance is fine most of
the time; always vetoing a new form just because it is new is
overdoing it.
Point five seems like simply another way of saying, in a more
generic way, the view raised in point four, or maybe points four
and one in combination. Same response as was given above.
I might summarize my reactions as follows. I am philosophically
opposed to the idea that code should only ever be written in common
forms or that it should be "dumbed down" for less sophisticated
developers. An advantage of C is that it is small enough so any
experienced developer can understand all of it. If someone isn't
capable of handling basic expressions like those under discussion
here then they just shouldn't be programming.
Incidentally, I might agree with you in the sense that I think
the semantics for the code being considered can be effected using
code that is either more familiar, or easier to follow than how
it was written above, or both. If that is your actual underlying
objection then I think we are pretty much on the same page. My
response above though gives reactions to what was written, not
what I imagined you were thinking.
do { quit; } else { }
Re: do { quit; } else { }