I miss loop

[cj]

Wow, not just anyone but a respected member of the community
recommending me to use goto. That took guts! I hope the community
still respects him.

Well, in case you haven't read all the other branches of this message I
can't seem to go against all these years of negative public opinion. I
decided to use nested do loops. I still think this is one time goto is
actually a practical, legitimate, and indeed inspired idea. I wish I
had the guts to use it. Herfried, your opinions are always welcome in
my posts.

 

[cj]

Yes, that works too but requires me to enclose every segment of the code
in if else statements checking to see if it's ok to do it. I did use
this type of code in one place except I called it loopError and set it
to False and if it remains false It does all the ifs. Strangely next to
the non existent loop/continue statement goto would seem to create the
most readable and compact code. The example in VB.net 2003's help for
goto is an example of a bad use of goto.

 

[cj]

Gee, I'm getting lots of support on this topic. Sounds like something
that needs discussing. I've done lots of batch files and you sure do
have to get, shall we say creative, to branch and make decisions.

Look familiar:

@echo off
if %1. == full. goto full
if %1. == FULL. goto full
goto mod
:full

In reviewing some of this just now I see one thing that would need to be
considered in choosing goto vs nested loops. I'm not sure but I suspect
the functionality of the not in VB.net 2003 loop/continue statement
would work more like the nested loops alternative than the goto
alternative. In a nested loop situation the exit sub would exit the
inner loop and therefore you'd re-enter the loop with any variables
declared inside the loop being refreshed, for lack of a better word. I
haven't tried but I get the impression from the help that goto can't be
used to jump outside a loop (to the line above it) so it could be
restarted, hence goto could only be used to go to the first line inside
the loop. variables inside the loop would not be refreshed they would
be as they existed before the goto was executed. This could be good or
it could be bad. Just has to be checked into and considered.

 

[cj]

Thanks for all the support. I posted this to Mythran also but I wanted
to make sure you saw it as well.

In reviewing some of this just now I see one thing that would need to be
considered in choosing goto vs nested loops. I'm not sure but I suspect
the functionality of the not in VB.net 2003 loop/continue statement
would work more like the nested loops alternative than the goto
alternative. In a nested loop situation the exit sub would exit the
inner loop and therefore you'd re-enter the loop with any variables
declared inside the loop being refreshed, for lack of a better word. I
haven't tried but I get the impression from the help that goto can't be
used to jump outside a loop (to the line above it) so it could be
restarted, hence goto could only be used to go to the first line inside
the loop. variables inside the loop would not be refreshed they would
be as they existed before the goto was executed. This could be good or
it could be bad. Just has to be checked into and considered.

 

[cj]

It sure has been nice discussing this here. I guess I found a subject
that many folks have encountered. There are lots of way to tackle the
problem. The continue/loop functionality I hoped existed in VB.Net 2003
for the do loop structure would be a perfect for this job. Since it
isn't I keep looking to find the next most perfect solution. Still I
don't have infinite time so I went with the nested do loop. It's not
perfect but it'll get the job done. When I have more time I'm going to
look into the goto some. Might have to put it back into service in this
one specific type of situation.

I need to get 2005 loaded and see what's in it sometime but that'll
probably be a few more months.

 

[cj]

Ooops, I refered to exit sub where I meant exit do.

 

[cj]

Ooops, I said exit sub where I meant exit do.

Gee, I'm getting lots of support on this topic. Sounds like something
that needs discussing. I've done lots of batch files and you sure do
have to get, shall we say creative, to branch and make decisions.

Look familiar:

@echo off
if %1. == full. goto full
if %1. == FULL. goto full
goto mod
:full

In reviewing some of this just now I see one thing that would need to be
considered in choosing goto vs nested loops. I'm not sure but I suspect
the functionality of the not in VB.net 2003 loop/continue statement
would work more like the nested loops alternative than the goto
alternative. In a nested loop situation the exit sub would exit the
inner loop and therefore you'd re-enter the loop with any variables
declared inside the loop being refreshed, for lack of a better word. I
haven't tried but I get the impression from the help that goto can't be
used to jump outside a loop (to the line above it) so it could be
restarted, hence goto could only be used to go to the first line inside
the loop. variables inside the loop would not be refreshed they would
be as they existed before the goto was executed. This could be good or
it could be bad. Just has to be checked into and considered.

 

[Sebastian]

I think you may have misunderstood the suggestion for using goto. Make
the goto go to the end of the loop, not the beginning, and you get
exactly the functionality of a continue statement, no messy inner loop.

Ex:
do

 

[Mythran]

Thanks for all the support. I posted this to Mythran also but I wanted to
make sure you saw it as well.

In reviewing some of this just now I see one thing that would need to be
considered in choosing goto vs nested loops. I'm not sure but I suspect
the functionality of the not in VB.net 2003 loop/continue statement would
work more like the nested loops alternative than the goto alternative. In
a nested loop situation the exit sub would exit the inner loop and
therefore you'd re-enter the loop with any variables declared inside the
loop being refreshed, for lack of a better word. I haven't tried but I
get the impression from the help that goto can't be used to jump outside a
loop (to the line above it) so it could be restarted, hence goto could
only be used to go to the first line inside the loop. variables inside
the loop would not be refreshed they would be as they existed before the
goto was executed. This could be good or it could be bad. Just has to be
checked into and considered.

Depends how you write it...

Your explanation is correct if written this way:

[begin loop]
[:MyLabel]
[do stuff]
[goto MyLabel]
[end loop]

You explanation is in-correct if written this way:

[begin loop]
[goto MyLabel]
[do stuff]
[:MyLabel]
[end loop]

So placing the label right before the loop re-starts will make it
iterate/increment properly

Mythran

 

[cj]

Quite true indeed.

Thanks for all the support. I posted this to Mythran also but I
wanted to make sure you saw it as well.

In reviewing some of this just now I see one thing that would need to
be considered in choosing goto vs nested loops. I'm not sure but I
suspect the functionality of the not in VB.net 2003 loop/continue
statement would work more like the nested loops alternative than the
goto alternative. In a nested loop situation the exit sub would exit
the inner loop and therefore you'd re-enter the loop with any
variables declared inside the loop being refreshed, for lack of a
better word. I haven't tried but I get the impression from the help
that goto can't be used to jump outside a loop (to the line above it)
so it could be restarted, hence goto could only be used to go to the
first line inside the loop. variables inside the loop would not be
refreshed they would be as they existed before the goto was executed.
This could be good or it could be bad. Just has to be checked into
and considered.

Depends how you write it...

Your explanation is correct if written this way:

[begin loop]
[:MyLabel]
[do stuff]
[goto MyLabel]
[end loop]

You explanation is in-correct if written this way:

[begin loop]
[goto MyLabel]
[do stuff]
[:MyLabel]
[end loop]

So placing the label right before the loop re-starts will make it
iterate/increment properly

Mythran

 

[cj]

Yes, that'll also work.

I think you may have misunderstood the suggestion for using goto. Make
the goto go to the end of the loop, not the beginning, and you get
exactly the functionality of a continue statement, no messy inner loop.

Ex:
do
.
if something goto LoopContinue
.
.
.
if something goto LoopContinue
.
if something goto LoopContinue
.

LoopContinue:
while continue

 

[Tim Ferguson]

Strangely next to
the non existent loop/continue statement goto would seem to create the
most readable and compact code.

Yebbut, Nobbut, Yebbut, Nobbut Yeah, you see... it's all about how far the
Goto GetOutOfHereNow is from the :GetOutOfHereNow. In many implementations
they end up a long way away, and it's the code-maintainer that comes along
later and doesn't spot it.

For my money, structured programming is all about putting code into little
self-contained boxes, and any path that suddenly arrives at another point
with several different possibilities for variables that have been
initialised or not, files that have been opened or closed or not, etc etc
is asking for trouble. YMMV of course.

All the best


Tim F

 

[cj]

Very true. I'd add that not only is it bad practice to have a GoTo too
far from the label, it is just as bad to have too many lines of code
within an if, loop, do or whatever statement. If the top and bottom of
the code are close enough to be enclosed in a do loop the goto wouldn't
be a problem.

Also lets not forget what others have pointed out as well. Proper
naming is critical in anything. GoTo GetOutOfhere Now wouldn't be as
nice as GoTo BottomOfContinueLoop assuming I'm using Do, While Continue
as the loop. Heck for that matter Continue is a bad choice of names in
most situations. It'd be better to use Do, While GetNewShippingRecords
or something. Except that Continue is easily readable and
understandable in this specific app.

I'd further mention, and it's a pet peeve of mine, that I've seen these
little self contained boxes used to the point that they make code
unreadable. Some folks, and I'm not insinuating your one of them, use
them to such a point that he main code has nothing in it but calls and
then you find all it does is call others. Your jumping all over the
place to see what the next subroutine does and it becomes its own form
of spaghetti code. If you don't have to call a routine but from one
place you might not need to put it in a routine. Might, I said.
Sometimes it's good of course, like to remove a huge section of distinct
code to keep routines short enough to read.