Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Sun, 11 May 2025 23:48:26 -0700 Organization: A noiseless patient Spider Lines: 127 Message-ID: <86wmamxr2d.fsf@linuxsc.com> References: <20250413072027.219@kylheku.com> <20250415053852.166@kylheku.com> <20250416173721.000030b5@yahoo.com> <86ecx13nfb.fsf@linuxsc.com> <20250507123232.00005f8b@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 12 May 2025 08:48:35 +0200 (CEST) Injection-Info: dont-email.me; posting-host="74b4e5895be58ca73eb02e8f9ff401e1"; logging-data="1024033"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19YD3Bqy0S/pDb65MlxjmIheHUBeJnNco8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:INomLRtczzIaV/oGslNbn6SMbaA= sha1:hD0ooDzbt6rJDGX5dJTUewcZtvU= Xref: csiph.com comp.lang.c:393338 Michael S writes: > On Tue, 06 May 2025 05:59:20 -0700 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Wed, 16 Apr 2025 14:09:44 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: >>> >>>> bart 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.