"Continue" usage

[Richard]

Re: "Continue& quot; usage

Chris Dollin <chris.dollin@h p.comwrites:

Richard wrote:
>

>Chris Dollin <chris.dollin@h p.comwrites:
>>

>>mdh wrote:
>>>
>>>May I ask the group this somewhat non-focused question....hav ing now
>>>seen "continue" used in some of the solutions I have worked on. ( Ex
>>>7-4 solution by Tondo and Gimpel comes to mind)
>>>Is there a good principle/s for the good usage of "continue"...or ...do
>>>any of the regular/irregular contributors have a "favorite" way in
>>>which it is particularly useful. Thanks as usual.
>>>
>>I have seen `continue` used sensibly [1] so rarely
>>that I treat any use of it
>>as a code smell
>>suggesting
>>that there is an opportunity
>>to fix the design
>>in a way that eliminates any need
>>to consider continue for that code.
>>>
>>To indicate an empty loop body
>>I find `{}` perfectly adequate
>>on those odd occasions
>>when it is needed.
>>>
>>Mind the gap.
>>>
>>[1] From my POV, natch.

>>
>Actually it makes perfect sense when you have your gate condition at the
>top of the section - far easier to read, understand and maintain in many
>cases (not all of course).
>>
>while(n--){
>>
> if(complexCondi tionNotMatched( n))
> continue; /* not interested. Check the next if there is one. */
>>
> /*do processing of things we are interested in*/
>>
>}

>
This is exactly the kind of example that I find smelly. (Weakly
smelly, but still smelly.)

Wierd. I see the above and it is 100% clear and concise. No scrolling
needed. No guesswork. In fact I can not think of anything better for
this.

>
I would write the utterly obvious:
>
while (n--)
if (complexConditi onMatched(n))
doInterestingTh ings(n);
>
(Add layout and braces and inlined function body to taste.)

Of course. And the scroll down to see what, if anything, is on the else
part. Already more complicated.

>

>Now we could invert the test but then we need to scroll down to the end
>of the function to be see what else happens after the block.

>
No, we don't. We just look; functions are not /that/ big, especially

Immaterial. They can be. My way makes it immaterial anyway.

nowadays, and editors are not that feeble, so I'm told.

I guess you are trying to belittle my comments with that?

>

>Seems clear, maintainable and decent design to me. I fail to see how it
>could be construed as "bad" in any shape or form.

>
It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

It is totally clear.

If I am not interested in this element then check the next one. What
could be easier. I suspect you have made your mind up so any more
discussion will be a waste of time.

[Chris Dollin]

Re: &quot;Continue& quot; usage

Richard wrote:

Chris Dollin <chris.dollin@h p.comwrites:
>

>No, we don't. We just look; functions are not /that/ big, especially

>
Immaterial. They can be. My way makes it immaterial anyway.

If a function is as big as you suggest, you have already lost.

>nowadays, and editors are not that feeble, so I'm told.

>
I guess you are trying to belittle my comments with that?

Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.

>>Seems clear, maintainable and decent design to me. I fail to see how it
>>could be construed as "bad" in any shape or form.

>>
>It's not a clear statement of intent; or, more exactly, it's not as
>clear a statement as one could write with similar effort.

>
It is totally clear.

There's an unnecessary `continue` in it that isn't contributing
to clarity. I expect constructs like `continue` that play with
control flow to pull their weight and not just substitute for
syntactic rearrangements. The power of `continue` is that it
can leap out of nested blocks and conditionals; the price of
`continue` is that you have to track down what it skips and
where it goes in a way that you don't with the "structured "
constructs. Forcing this on the reader is a load; forcing them
when a straightforward rearrangement makes it unnecessary
and IMAO adds clarity is just ... untidy.

If I am not interested in this element then check the next one. What
could be easier.

if this is interesting, process it

is easier.

I suspect you have made your mind up so any more
discussion will be a waste of time.

Of course I've made my mind up; if you want to convince me
otherwise, you need a better argument that doesn't ignore mine.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Chris Dollin]

Re: &quot;Continue& quot; usage

Richard wrote:

Once more
>
while(n--){
>
if(complexCondi tionNotMatched( n))
continue; /* not interested. Check the next if there is one. */
>
/*do processing of things we are interested in*/
}
>
Has to be easier to comprehend and check than:
>
while(n--){
>
if(complexCondi tionMatched(n)) {
/*do processing of things we are interested in*/
}
>
}

There's no "has to be"; it just /isn't/ easier (for me) than
the intent-displaying code.

because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.

In your example, I can just see what happens. If you had a whole
mess of code in there, I'd do an Extract Method\\\\\\Fun ction on
it and mutter Dark Words about whoever had written the mess.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard]

Re: &quot;Continue& quot; usage

Chris Dollin <chris.dollin@h p.comwrites:

Richard wrote:
>

>Chris Dollin <chris.dollin@h p.comwrites:
>>

>>No, we don't. We just look; functions are not /that/ big, especially

>>
>Immaterial. They can be. My way makes it immaterial anyway.

>
If a function is as big as you suggest, you have already lost.

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

>

>>nowadays, and editors are not that feeble, so I'm told.

>>
>I guess you are trying to belittle my comments with that?

>
Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.

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

>

>>>Seems clear, maintainable and decent design to me. I fail to see how it
>>>could be construed as "bad" in any shape or form.
>>>
>>It's not a clear statement of intent; or, more exactly, it's not as
>>clear a statement as one could write with similar effort.

>>
>It is totally clear.

>
There's an unnecessary `continue` in it that isn't contributing
to clarity.

Says you. I have explained why it is contributing to clarity. What YOU
exect is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design. 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(complexCondi tionNotMatched( n))
continue; /* not interested. Check the next if there is one. */

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

}

*snip*

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.

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

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

[Ben Bacarisse]

Re: &quot;Continue& quot; usage

Richard<rgrdev@ gmail.comwrites :

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

<big snip>

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

>No, there is nothing you can add for clarity. Please don't take the
>fact that you may not always able to persuade as being evidence that
>your readers don't comprehend.

>
I do not. But I am a bit bewildered by your arguments here. Nothing you
have said is easier or "more maintainable" (in my mind of course) than
my example which is concise, easy to read and very, very localised
without the need to check for else statements.
>
Once more
>
while(n--){
>
if(complexCondi tionNotMatched( n))
continue; /* not interested. Check the next if there is one. */
>
/*do processing of things we are interested in*/
}
>
Has to be easier to comprehend and check than:
>
while(n--){
>
if(complexCondi tionMatched(n)) {
/*do processing of things we are interested in*/
}
>
}
>
because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.

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.
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
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 .

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
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).

--
Ben.

[Richard]

Re: &quot;Continue& quot; usage

Chris Dollin <chris.dollin@h p.comwrites:

Richard wrote:
>

>Once more
>>
>while(n--){
>>
> if(complexCondi tionNotMatched( n))
> continue; /* not interested. Check the next if there is one. */
>>
> /*do processing of things we are interested in*/
>}
>>
>Has to be easier to comprehend and check than:
>>
>while(n--){
>>
> if(complexCondi tionMatched(n)) {
> /*do processing of things we are interested in*/
> }
>>
>}

>
There's no "has to be"; it just /isn't/ easier (for me) than
the intent-displaying code.

Because you hate continues. The reason it has to be when using metrics
like code length is simple:

its less code

its less to browse

there is no else to worry about

we jump back to start of loop while still visible when debugging.

I can not see one single negative in that code above.

Not one.

>

>because in the second block one MUST go down to check the end of the
>function to see what happens for the non matched element.

>
In your example, I can just see what happens. If you had a whole
mess of code in there, I'd do an Extract Method\\\\\\Fun ction on
it and mutter Dark Words about whoever had written the mess.

I'm quite sure you would. Me? I would say "Oh that first few lines makes
it perfectly clear what elements we are interested in processing and
which not.

[Richard]

Re: &quot;Continue& quot; usage

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

Richard<rgrdev@ gmail.comwrites :
>

>Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

<big snip>
>
I don't think there are any substantive issues there than this:
>

>>No, there is nothing you can add for clarity. Please don't take the
>>fact that you may not always able to persuade as being evidence that
>>your readers don't comprehend.

>>
>I do not. But I am a bit bewildered by your arguments here. Nothing you
>have said is easier or "more maintainable" (in my mind of course) than
>my example which is concise, easy to read and very, very localised
>without the need to check for else statements.
>>
>Once more
>>
>while(n--){
>>
> if(complexCondi tionNotMatched( n))
> continue; /* not interested. Check the next if there is one. */
>>
> /*do processing of things we are interested in*/
>}
>>
>Has to be easier to comprehend and check than:
>>
>while(n--){
>>
> if(complexCondi tionMatched(n)) {
> /*do processing of things we are interested in*/
> }
>>
>}
>>
>because in the second block one MUST go down to check the end of the
>function to see what happens for the non matched element.

>
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:

>while(n--){
>>
> if(complexCondi tionNotMatched( n))
> continue; /* not interested. Check the next if there is one. */
>>
> /*do processing of things we are interested in*/
>}

>
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]

Re: &quot;Continue& quot; usage

Richard wrote:

Chris Dollin <chris.dollin@h p.comwrites:
>

>Richard wrote:
>>

>>Chris Dollin <chris.dollin@h p.comwrites:
>>>
>>>No, we don't. We just look; functions are not /that/ big, especially
>>>
>>Immaterial. They can be. My way makes it immaterial anyway.

>>
>If a function is as big as you suggest, you have already lost.

>
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.

>>>nowadays, and editors are not that feeble, so I'm told.
>>>
>>I guess you are trying to belittle my comments with that?

>>
>Your guesswork is wonky. That's not a statement about you, or
>your comments, but about modern programmer's-editors.

>
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.

>>>>Seems clear, maintainable and decent design to me. I fail to see how it
>>>>could be construed as "bad" in any shape or form.
>>>>
>>>It's not a clear statement of intent; or, more exactly, it's not as
>>>clear a statement as one could write with similar effort.
>>>
>>It is totally clear.

>>
>There's an unnecessary `continue` in it that isn't contributing
>to clarity.

>
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 misrepresentati on, 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!

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Richard]

Re: &quot;Continue& quot; usage

Chris Dollin <chris.dollin@h p.comwrites:

Richard wrote:
>

>Chris Dollin <chris.dollin@h p.comwrites:
>>

>>Richard wrote:
>>>
>>>Chris Dollin <chris.dollin@h p.comwrites:
>>>>
>>>>No, we don't. We just look; functions are not /that/ big, especially
>>>>
>>>Immaterial . They can be. My way makes it immaterial anyway.
>>>
>>If a function is as big as you suggest, you have already lost.

>>
>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.
>

>>>>nowadays, and editors are not that feeble, so I'm told.
>>>>
>>>I guess you are trying to belittle my comments with that?
>>>
>>Your guesswork is wonky. That's not a statement about you, or
>>your comments, but about modern programmer's-editors.

>>
>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.

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

>

>>>>>Seems clear, maintainable and decent design to me. I fail to see how it
>>>>>could be construed as "bad" in any shape or form.
>>>>>
>>>>It's not a clear statement of intent; or, more exactly, it's not as
>>>>clear a statement as one could write with similar effort.
>>>>
>>>It is totally clear.
>>>
>>There's an unnecessary `continue` in it that isn't contributing
>>to clarity.

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

>
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]

Re: &quot;Continue& quot; usage

Richard<rgrdev@ gmail.comwrites :

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:
>

>Richard<rgrdev @gmail.comwrite s:
>>

>>Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

><big snip>
>>
>I don't think there are any substantive issues there than this:
>>

>>>No, there is nothing you can add for clarity. Please don't take the
>>>fact that you may not always able to persuade as being evidence that
>>>your readers don't comprehend.
>>>
>>I do not. But I am a bit bewildered by your arguments here. Nothing you
>>have said is easier or "more maintainable" (in my mind of course) than
>>my example which is concise, easy to read and very, very localised
>>without the need to check for else statements.
>>>
>>Once more
>>>
>>while(n--){
>>>
>> if(complexCondi tionNotMatched( n))
>> continue; /* not interested. Check the next if there is one. */
>>>
>> /*do processing of things we are interested in*/
>>}
>>>
>>Has to be easier to comprehend and check than:
>>>
>>while(n--){
>>>
>> if(complexCondi tionMatched(n)) {
>> /*do processing of things we are interested in*/
>> }
>>>
>>}
>>>
>>because in the second block one MUST go down to check the end of the
>>function to see what happens for the non matched element.

>>
>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.

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.

>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.

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?

>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.

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:
>

>>while(n--){
>>>
>> if(complexCondi tionNotMatched( n))
>> continue; /* not interested. Check the next if there is one. */
>>>
>> /*do processing of things we are interested in*/
>>}

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.

>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?

In message-ID: <gb84sk$qvh$1@r egistered.motza rella.org>. 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.
>

>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

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.

--
Ben.

[Richard Harter]

Re: &quot;Continue& quot; usage

On Mon, 22 Sep 2008 08:11:39 -0400, Eric Sosman
<esosman@ieee-dot-org.invalidwrot e:

>mdh wrote:

>May I ask the group this somewhat non-focused question....hav ing now
>seen "continue" used in some of the solutions I have worked on. ( Ex
>7-4 solution by Tondo and Gimpel comes to mind)
>Is there a good principle/s for the good usage of "continue"...or ...do
>any of the regular/irregular contributors have a "favorite" way in
>which it is particularly useful. Thanks as usual.

>
Hi, my name is Eric, and I'm a `continue' abuser. I use
>it as a disguised `goto', simply to avoid excessive nesting:
>
> for (...) {
> ... prepare for a test ...
> if (not_applicable )
> continue;
> ... prepare another test ...
> if (not_applicable _2)
> continue;
> ... payload ...
> }
>
>Inverting the sense of the tests would eliminate my abusive
>`continue' statements:
>
> for (...) {
> ... prepare for a test ...
> if (! not_applicable) {
> ... prepare another test ...
> if (! not_applicable_ 2) {
> ... payload ...
> }
> }
> }
>
>... but if there are three or four such tests, as often
>happens when you're converting and validating input from
>an uncontrolled source, the "payload" -- the real purpose
of the function --
tends to get squee-
> zed into short
little lines all
crowded at the right-
hand side and larded
with ugly line bre-
aks.
>
So although I know in my heart of hearts that I overuse
>`continue' and really shouldn't, the way I really shouldn't
>drink and smoke and gamble on cockfights, I, er, continue in
>my disgusting habit. There, I've admitted my guilty secret.
>They say it's the first step to recovery, but only time will
>tell.

Speaking as a fellow sinner, I'm with Eric on this one. Unlike
Eric I'm unrepentent - I think it's a case of doing the best one
can with a defective tool.

OT
I look at this as a language design issue. There is a specific
software pattern involved here that I call a filter. We do X if
something passes tests t1, t2, etc. If the tests can be written
as simple boolean expressions then C provides short circuit
evaluation, e.g.,

if(t1 && t2 ...) X

However that doesn't work if there intermediate prep work is
required. There is IMOWINTBQ (In my opinion which is not to be
questioned) a "right" way to do it available in some languages,
the andif construct. The andif blocks can follow if blocks and
other andif blocks - they are short circuit forms at the block
level. Thus we would write:

if (t1) {
... prep work ...
} andif (t2) {
... prep work ...
} andif (t3) {
... payload ...
}

(Use whatever layout floats your boat)

Since C doesn't have an andif or equivalent we have to fake it.
(Deep nesting ifs is not a solution - it is a disease.) Using
continue is a solution of sorts and one that I am comfortable
with but it has its faults. The first is that it must be within
a loop. The second is that to use it you have to invert the
tests. The third is that it is immoral and fattening. Still,
there is no solution in C that is not weird in some way.

/OT


Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Eric Sosman]

Re: &quot;Continue& quot; usage

mdh wrote:

On Sep 22, 5:11 am, Eric Sosman <esos...@ieee-dot-org.invalidwrot e:
>

> Hi, my name is Eric, and I'm a `continue' abuser.

>
>
LOL...
>
Thanks Eric and all who replied. More hooks to hang my ideas on. Much
Appreciated.

It occurs to me that I've still not revealed my worst
abuse of `continue'; I have further sins to confess. Having
just returned from a wake and being filled with intimations
of mortality, I hereby unburden my soul:

This particular abuse arose in connection with processing
command-line arguments. I'd loop through the argv[] array and
look up each argument in an array of strings representing the
command-line flags. Then I'd `switch' on the array index to get
to flag-specific processing. Some flags stood alone, some required
a value from a following argument, some of those values got
converted to numbers and range-checked, nothing very surprising.

But every `case' for a flag that gobbled a following value had
to check whether another argument actually existed, lest it run
off the end of the argv[] array. And I wondered: Could I somehow
rearrange things so at least part of the check-for-more code
could be factored out and de-duplicated?

Here, O my brethren, is the pit of sin into which I fell:

for (i = 1; i < argc; ++i) {
id = ... index of argv[i] in flags array ...;
switch (id) {
case 0: /* -x */
x_flag = 1;
continue;
case 1: /* -p path */
if (++i < argc) {
p_path = argv[argc];
continue;
}
break;
case 2: /* -n number */
if (++i < argc) {
n = ... numeric value of argv[i] ...;
if (0 < n && n < 42) {
n_value = n;
continue;
}
}
break;
default:
fprintf (stderr, "\"%s\" is not recognized\n",
argv[i]);
return -1;
}
fprintf (stderr, "Invalid or missing value after %s\n",
flags[id]);
return -1;
}
return 0;

Take heed, sinners: The slope is steep and slippery. It
starts easy, like a few idle puffs of maryjane, but the
descent to crack and smack and horse and worse is easier still.
Abuse `continue' at your peril!

(And, I've still got to admit, at your pleasure.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

[CBFalconer]

Re: &quot;Continue& quot; usage

Ben Bacarisse wrote:

Richard<rgrdev@ gmail.comwrites :
>

.... snip ...

>

>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?

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: &quot;Continue& quot; usage

Ben Bacarisse wrote:

Eric Sosman <esosman@ieee-dot-org.invalidwrit es:
>
<snip>
>

>Hi, my name is Eric, and I'm a `continue' abuser. I use it as
>a disguised `goto', simply to avoid excessive nesting:

>
<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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Nick Keighley]

Re: &quot;Continue& quot; usage

On 22 Sep, 15:52, Richard<rgr...@ gmail.comwrote:

Chris Dollin <chris.dol...@h p.comwrites:

Richard wrote:

Chris Dollin <chris.dol...@h p.comwrites:

<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(complexCondi tionNotMatched( n))
      continue; /* not interested. Check the next if there is one. */
>
   /*do processing of things we are interested in*/
>
}

<snip>

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 (complexConditi oMatched(n))
do_processing_o f_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 (!complexCondit ionMatched(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