"Continue" usage

[Richard]

<big snip>

I don't think there are any substantive issues there than this:


Why are you bringing up "easier to understand" -- I agreed about that
several messages ago?

The only issue I raised was maintainability. Now, I have admitted
that I don't really know what people mean here, but you brought it up
so it must mean something to you. I asked for an example of something
that, in your view impairs maintainability, but you did not offer one.

I thought it was obvious from the context. The less code needed to
understand a certain branch the better. That is one aspect of it.

Without that I will be at a disadvantage, because I don't know what I
mean by it and you haven't said what you mean by it!

Other people seem to hold that code is more maintainable if it can be
modified by making "local changes". I posited a change: add something
that has to be done every time after the loop's (current) body. To do

sure. In that case dont use continue : change it to an empty block
followed by an else. Easy enough

while(n--){
if(!cond(n)){
/*do nothing*/
}else{
/*do something*/
}

something to do all the time:
}

Not exactly rocket science.

that, if a loop has a continue, the maintenance programmer has to
check for that and either replace the continue with a goto or re-write
using an if that encloses the (current) body. Neither is what I
understand by a "local change".

This may not be what you mean by maintainability, in which case you
use is (by your criteria) unimpeachable, but it seems to match what I
think other people call maintainability.

Your example is fair and one aspect of it. It means many things to many
people.

But one of the most important is the ability to see what peoples code is
doing at a glance and assuming this code is working as desired I can
only consider that a total nOOb or fool would NOT understand what the
following code does for elements which do not match the criteria for
further processing:

Please don't repeat that your code if for cases where this change is
never warranted. If you can code for all future changes you should
write a book to tell the rest of how to do this. If, on the other

Where did I say that? I am merely saying (and as usual in c.l.c it gets
dragged through the bushes backwards) that "continue" is not an
indicator that code is poorly designed in any shape or form.

hand, you claim that this change is never need in loops that have this
specific pattern, then I'll shut up and just accept you have a much
deeper knowledge of code patterns than I have ever managed to attain
(but you should have brought up the fact that you know this never
happens when you offered the code pattern).

I offered the "pattern" for the reasons stated above. I'm sure you dont
mean to sound like you are posturing with your qualifications with that
last statement, but I'm not offering my POV to have a pissing
competition. I think that Chris' original statement about using continue
is ill founded and incorrect and I have offered reasons for it. I dont
know what you mean by "code patterns" in this respect - it seems it just
muddies the waters and takes the conversation into a totally different
realm.

Using "continue" is simply NOT an indicator of a poor design.

 

[Chris Dollin]

Do you notice your "if" there? Why are you second guessing what the nex
block is like?

I'm not. If it's small, there is no problem. If it's big, the
code is -- in general -- /already/ smelly. Fix that first.

I know all about modern editors. But why even bring them up. they are
immaterial to the point in hand.

Because /you/ were complaining about the overhead of having to scroll
to find the end of the loop and thus that there's no else clause.
I believe this is a non-issue for reasons presented in this thread.

Says you. I have explained why it is contributing to clarity.

Yes, I have understood your special-case argument.

What YOU
exect is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design.

Suggests. (Indicates is too strong.) And not /broken/ -- one that
can be improved.

I have given a
very simple use of it which is clear,
Ish.

concise
Yes.

and requires less code browsing
Unproven.

to see what happens when an element is not suitable for
processing.

Here, I will show you again:

I'm not bloody deaf, nor yet senile. Give over.

Now it obvious to me that you have a thing against continue and no
amount of logical argument will convince you otherwise. The fact that
you are reaching for an editors functionality to make that "extra
browsing" painless is proof in the pudding to me that further
argument/discussion is pointless.

See above.

Bottom line is : you think they are bad and are used by poor programmers
to cover up poor design.

I think they /suggest/ an opportunity for /design improvement/, and
I have nowhere restricted my statements to /poor programmers/. Don't
misrepresent my position, ridicule the misrepresentation, and then
claim to have won the argument. It does not strengthen your position.

I think the above is very well designed and crystal clear.

I think it's an unnecessary complication.

Andy is waving goodbye!

 

[Richard]

I'm not. If it's small, there is no problem. If it's big, the
code is -- in general -- /already/ smelly. Fix that first.


Because /you/ were complaining about the overhead of having to scroll
to find the end of the loop and thus that there's no else clause.
I believe this is a non-issue for reasons presented in this thread.

Sigh. In my method there is no question of it anyway. Do you not see
that. I was not "complaining" either. I was merely pointing out there
was no need with the continue. Holy of holies.

Yes, I have understood your special-case argument.

Special case?

So you acknowledge that this "special case" is not a broken design?

Good. My job is done.

 

[Ben Bacarisse]

I thought it was obvious from the context. The less code needed to
understand a certain branch the better. That is one aspect of it.

I thought that was covered by "clarity". Your original claim was that
is was clear and maintainable. If maintainable code just has to be
clear then, I agree, you are done. I think maintainable code has to
be easily alterable, and this sometimes requires more than just
clarity.

sure. In that case dont use continue : change it to an empty block
followed by an else. Easy enough

while(n--){
if(!cond(n)){
/*do nothing*/
}else{
/*do something*/
}

something to do all the time:
}

Not exactly rocket science.

I know. This is why I wanted you to say what you mean by
maintainable. If code is maintainable despite having to make such
changes, I want to know what you consider to be harmful to
maintainability. Otherwise all code is maintainable (provided it is
clear) and you could have just said "this code is clear" -- implying
that it is therefore (by your definition) maintainable. What, in
addition to clarity, were you claiming by saying it is maintainable?

Your example is fair and one aspect of it. It means many things to many
people.

If you said what it means to you, we could avoid going round again.

But one of the most important is the ability to see what peoples code is
doing at a glance and assuming this code is working as desired I can
only consider that a total nOOb or fool would NOT understand what the
following code does for elements which do not match the criteria for
further processing:

Simply someone who because the loop is long (as you concede is
possible) misses the continue when adding code at the end. I get the
idea from some people that robust maintainable code has to defend
against such simple mistakes. If you don't worry about that, then you
have defined the problem away.

Where did I say that?

In message-ID: <[email protected]>. When I first
suggest the possibility of having to add such code you said:

| Yes. if you need to. In this case you do not need to. It is very
| clear.

which suggested to me you were discounting a whole bunch future of
changes right form the start.

I am merely saying (and as usual in c.l.c it gets
dragged through the bushes backwards) that "continue" is not an
indicator that code is poorly designed in any shape or form.


I offered the "pattern" for the reasons stated above. I'm sure you dont
mean to sound like you are posturing with your qualifications

No. I have no qualifications to posture about. I have always tried
to allow for local changes which, to my mind, rules out your usage of
continue. But you speak as if you have very much greater experience of
software development than I do, so if you tell me that this is not a
problem -- that you'd expect maintenance programmers to spot the
continue and change it if needed -- I have to accept it. I have no
experience to counter your claim. Other people might, but I don't.

with that
last statement, but I'm not offering my POV to have a pissing
competition. I think that Chris' original statement about using continue
is ill founded and incorrect and I have offered reasons for it. I dont
know what you mean by "code patterns" in this respect - it seems it just
muddies the waters and takes the conversation into a totally different
realm.

Using "continue" is simply NOT an indicator of a poor design.

This is a stronger statement than I would make and not, I think, what
Chris was saying (but I should leave him to say). I understood him to
mean it should cause one to go check to see if there was not a better
way and in that respect (if that is what he means) I agree.

 

[CBFalconer]

.... snip ...


I know. This is why I wanted you to say what you mean by
maintainable. If code is maintainable despite having to make
such changes, I want to know what you consider to be harmful to
maintainability. Otherwise all code is maintainable (provided
it is clear) and you could have just said "this code is clear"
-- implying that it is therefore (by your definition)
maintainable. What, in addition to clarity, were you claiming
by saying it is maintainable?

IMO, ridiculous. Unnecessarily complex. You just want:

while (n--)
if (cond(n) {
/* do something */
}
/* something to do all the time */
}

No else, no continue, no extra lines, no confusion.

 

[CBFalconer]

<fx:stands up>
Hello, my name is Ben, and *I* abuse break. Ah, it feels so good
to say it out loud!

I never get tempted by continue (see elsethread) but I can't keep
my hands off that lovely break. It is sooooo tempting, when you
are all hot and bothered, tightly bound by a strict loop invariant,
just to slip in little break and be free.

Here is some more meat for disagreement and abuse. You can avoid
both break and continue. Simply use goto. Note that this has the
significant advantage that a short search of the code source shows
you the destination.

If the compiler can't optimize through this, I suspect the
optimizer is flawed.

 

[Nick Keighley]

<snip>

[the continue version isn't as clear]

Says you. I have explained why it is contributing to clarity. What YOU
[expect] is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design.

you're mind reading...

I have given a
very simple use of it which is clear, concise and requires less code
browsing to  see what happens when an element is not suitable for
processing.

Here, I will show you again:

while(n--){

   if(complexConditionNotMatched(n))
      continue; /* not interested. Check the next if there is one. */

   /*do processing of things we are interested in*/

}

I think the above is very well designed and crystal clear.

yes but I think (and apparently a few other people) that

while(n--)
{
if (complexConditioMatched(n))
do_processing_of_thing();
}

is clearer. For a start it avoids an inverted test.
I don't write predicates with "not" in the name. So
I would have coded your original example as

while(n--){
if (!complexConditionMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

there is some evidence (if forced to cite I'll try "The Psychology
of Computer Programming") that human beings (including computer
programnmers) prefer positive to negative logic.


--
Nick Keighley

When the Piranhas left school they were called up but were found
by an Army Board to be too unstable even for National Service.
Denied the opportunity to use their talents in the service of their
country, they began to operate what they called 'The Operation'.
They would select a victim and then threaten to beat him up if he
paid the so-called protection money. Four months later they started
another operation which the called 'The Other Operation'. In this
racket they selected another victim and threatened not to beat him
up if he didn't pay them. One month later they hit upon 'The Other
Other Operation'. In this the victim was threatened that if he
didn't pay them, they would beat him up. This for the Piranha
brothers was the turning point.
Monty Python The Pirana Brothers

 

[Chris Dollin]

is clearer. For a start it avoids an inverted test.
I don't write predicates with "not" in the name.

I don't think that's a fair criticism; I thought Richard's
`complexConditionNotMatched` was a standin for whatever
expression was required, with the `Not` showing intent,
not the actual presence of a `Not` in the name.

So
I would have coded your original example as

while(n--){
if (!complexConditionMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

there is some evidence (if forced to cite I'll try "The Psychology
of Computer Programming") that human beings (including computer
programnmers) prefer positive to negative logic.

I think there are subsequent studies in that direction, but I
don't have a cite to hand. One of my rantettes is against languages
that don't have an `unless`.

 

[CBFalconer]

.... snip ...

I think there are subsequent studies in that direction, but I
don't have a cite to hand. One of my rantettes is against
languages that don't have an `unless`.

How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */

 

[Ben Pfaff]

How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */

I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.

 

[Richard Bos]

I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.

In other words, if you want PERL, you know where to find it.
(A sentiment which I heartily endorse.)

Richard

 

[Chris Dollin]

I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.

Much as I like `unless`, I would not advocate this either. Dinking
around with control-structure macros is, I believe, a good way to
confuse the other programmers who might be working on your code.

/Sometimes/ you get enough ROI for it to be worthwhile, when the
macro(s) hide enough details in the right kind of way. I'm willing
to pay the !() price of an unless-less C; but any imperative language
I design has an `unless` conditional (and an `until` loop).

 

[Ben Pfaff]

Much as I like `unless`, I would not advocate this either. Dinking
around with control-structure macros is, I believe, a good way to
confuse the other programmers who might be working on your code.

/Sometimes/ you get enough ROI for it to be worthwhile, when the
macro(s) hide enough details in the right kind of way.

My favorite example of a worthwhile control structure macro is a
macro for iterating through linked lists constructed in clever
ways, so that code like

for (node = list; node != NULL; node = node->next) {
struct data *d = container_of(node, struct data, member);
...do something with d...
}

(or often much worse than that) can be condensed to something
like

struct data *d;
LIST_FOR_EACH (d, struct data, member, list) {
...do something with d...
}

which personally seems more readable.

 

[Antoninus Twink]

Simply use goto. Note that this has the significant advantage that a
short search of the code source shows you the destination.

More fantastic advice for the C newbie from CBF...