[RESOLVED] [2005] Skip to Next in 'For Each' loop?

[arsmakman]

Hello everyone:

I have a 'For Each' loop that contains some items I don't want to analyse. Now I use a GoTo command to 'skip' an item. But this is not very elegant and (knowing .NET) there is probably a way to skip to the next item without using GoTo.

I'll show you a simplified version of my loop, designed to add all animals to a list, except the Leopard :
(Indeed, simplified, because there's like two pages of code in the real loop. )

For Each Animal As String In Animals
        If Animal = "Leopard" Then GoTo OhNoALeopard
 
        ListBox.Items.Add(Animal)
 
OhNoALeopard:
    Next

Thanks for any help.

[penagate]

There is a way to do what you ask, but I'm not going to tell you, because it bears an equally great resemblance to long strands of Italian pasta as does your current Goto method.

The correct method is to surround all logic within the loop body in If() blocks, so nothing is executed unless the correct criteria are met. So rather than saying "If not this then skip", you would say "If this then do this".

This method ensures a logical, easy to follow code path, which in turn ensures easy debugging, expansion, and general maintainability for the future.

[arsmakman]

Do you mean I should put all the code that I want to execute if all criteria are met, in the Else part of my If-statement?

Hmm, the real loop also contains a lot of conditions that require 'skipping' halfway through the code. That would create a hellish If-statement jungle! Not so good...

I was really hoping for a more elegant solution.

[David Anton]

Continue For

[penagate]

Code can be as elegant as you make it.

Plan the logic flow before you start bashing the keyboard like the thousand proverbial monkeys, and unlike them you might have a chance of creating a work of Shakespeare


Edit:

[jmcilhinney]

It is preferable to avoid GoTo and Continue if possible, but there are situations where not using them will lead to more confusing code. Try to create an elegant solution by placing the code you want executed inside If blocks, but if doing so leads to more confusing code than would otherwise result then you haven't achieved the aim that the "rules" were created for in the first place. I'm all for principles if they aid or at least don't hinder, but as soon as the principle does hinder then it's out the window. Create the most elegant code you can. If that requires a Continue statement then use it.

[David Anton]

Code can be as elegant as you make it.

Plan the logic flow before you start bashing the keyboard like the thousand proverbial monkeys, and unlike them you might have a chance of creating a work of Shakespeare

Edit:

Well, let's see:
- Try/Catch is a goto
- Return is a goto
- Exit Sub is a goto
- Continue is a goto

Good luck with all those "If valid", "If Not Complete", "If ..." nestings. If your methods are about 5 lines long on average you can do it, but otherwise these goto's clarify the code rather than obscuring it.

[arsmakman]

'Continue For' does the trick neatly, thanks David.

jmcilhinney, I agree that If's are preferred in the majority of situations, but I have a lot of steps in processing the data, with almost each step, some of the data needs no further processing.
If this was all done with If statements, there would be over a dozen End If's before 'Next' and a huge intend would form, so I think 'Continue For' is preferrable here.

[jmcilhinney]

Isn't that what I said? If blocks are generally preferable but when they start making your code more confusing then they are less desirable. Having said that, it is quite possible, although by know means assured, that you could redesign your code to avoid the use of continue and still get the same result without the use of multiple indentations. Why don't you post this code and as a test let us see if we can restructure it to provide an elegant solution without multiple indentations or the use of Continue?

[BeckyBair]

I have VB6 code to post for someone to help me choose either IF statements or GOTO.

It is a large amount of code which makes me gravitate to the use of GOTO statements which is what I have put in for now.

Any and all help/suggestions is greatly appreciated.

I have attached the code in a txt file.

[jmcilhinney]

I have VB6 code to post for someone to help me choose either IF statements or GOTO.

It is a large amount of code which makes me gravitate to the use of GOTO statements which is what I have put in for now.

Any and all help/suggestions is greatly appreciated.

I have attached the code in a txt file.

There's really no choice to make. You should never use GoTo and you never need to. There is always another way to do whatever it is you need to do. The more code you have, the more likely that using GoTo will make your code harder to read and maintain, so that argument is actually opposite to what you think.

[penagate]

I stand by my earlier comments (made four years ago when this thread was active...)

Using nested branches gives you a hierarchical code flow which, even when complex, can be followed in a consistent manner. Using primitive jumps like GoTo and Continue destructures your code and in the worst cases can make it almost impossible to follow.

Generally the only "lower-level" instruction that is considered acceptable is Break (or Exit [Do|For|While] in Visual Basic). Even then, you should be thinking about whether or not you can rewrite the loop condition so that you don't need multiple exit points.

[BeckyBair]

Thank you for responding to my question on such an old thread/post.

[jmcilhinney]

Well, let's see:
- Try/Catch is a goto
- Return is a goto
- Exit Sub is a goto
- Continue is a goto

Good luck with all those "If valid", "If Not Complete", "If ..." nestings. If your methods are about 5 lines long on average you can do it, but otherwise these goto's clarify the code rather than obscuring it.

While that is to true to an extent, I don't think that it's really the same thing. I wouldn't really consider Try...Catch to be the same at all and all the others have a well-defined destination, i.e. either the end of the current loop or method or the beginning of the current loop. It's very easy to follow each of them because you know exactly where you'll end up. GoTo, on the other hand, can end up basically anywhere. When you reach a GoTo you have no idea whether you will be jumping forward or back and the destination could be nested pretty much at any level.

[David Anton]

I was exaggerating somewhat (way back then), but I still think that if you avoid all structured 'jumps' (Continue For, Exit For, etc.) that you end up with something far worse than what you're trying to avoid. That is, you end up with incredibly nested if/else blocks that has no more elegance than an unnested sequence with a couple of Continue's or Exit's thrown in.

This is also related to the old 'single exit point' rule for methods - it leads to code that is messier and harder to follow.