Exit Do

I've been instructed by a dot net / asp programmer that Exit Do is not a
great way to end a loop.

Can someone explain to me if this is so, or does this only apply to higher
level programming languages ?

I am using nested loops and need to exit out of one loop into another for
something to apply. Any other functional ways of doing this ?

Cheers,

Pegasus
Sat Mar 22 07:59:06 CDT 2008


"Robbie Flower" <rflower@hotmail.com> wrote in message
news:104f6a3f1b8e8ca5a85f8127d1a@msnews.microsoft.com...
>
> I've been instructed by a dot net / asp programmer that Exit Do is not a
> great way to end a loop.
>
> Can someone explain to me if this is so, or does this only apply to higher
> level programming languages ?
>
> I am using nested loops and need to exit out of one loop into another for
> something to apply. Any other functional ways of doing this ?
>
> Cheers,

I see no problem with "Exit do". If you do not wish to use it
then you would have to use conditional statements. Instead of
coding

do
success = SomeFunction(....)
if not success then exit do
. . .
loop
You could write
do
success = SomeFunction(....)
if success then
...
end if
loop

I prefer "exit" statements because they make the code
more readable.

ekkehard
Sat Mar 22 08:36:11 CDT 2008

Robbie Flower schrieb:
>
> I've been instructed by a dot net / asp programmer that Exit Do is not a
> great way to end a loop.
>
Ask him/her to define "great way".

> Can someone explain to me if this is so, or does this only apply to
> higher level programming languages ?
>
Code in *all* languages should be easy to understand and not relying
on tricks/surprises.

> I am using nested loops and need to exit out of one loop into another
> for something to apply. Any other functional ways of doing this ?
>
A loop should terminate on a clearly defined condition:

Do Until oTS.AtEndOfStream
sLine = oTS.ReadLine
... process sLine ...
Loop
oTS.Close

To handle special a special case by "Exit Do"

Do Until oTS.AtEndOfStream
sLine = oTS.ReadLine
... process sLine ...
If "no more interesting stuff" = sLine
Exit Do
End If
Loop
oTS.Close

looks ok to me, but you can use an extra variable instead:

bAbort = False
Do Until oTS.AtEndOfStream Or bAbort
...
If "no more interesting stuff" = sLine
bAbort = True
End If
Loop
oTS.Close

I think that this is more complicated (3 places to think about
bAbort and 1 Or to take into account), but YMMV.

If you use Exit Do/For/Sub/Function, you should be aware that
'jumping to the right place' in deeply nested constructs may
not be possible (no labels in VBScript).

mayayana
Sat Mar 22 08:34:38 CDT 2008


I can't imagine what that person was thinking.
Exit Do is a good way to make a loop more efficient
when you don't need it anymore. The same goes
for Exit For. And it often makes sense to use
more than one Exit Do in a loop. That applies to VB
and VBScript. I wouldn't expect .Net to be different,
but I don't know anything about .Net.

----------------
s = "abcdefghijk"
i = 1
L = len(s)
Do while i <= L
s2 = mid(s, i, 1)
if s2 = "g" then exit do
i = i + 1
Loop

msgbox i
-----------------
That code will show a msgbox with "7".
You could also have skipped the contingent
While code and put that into the loop:

i = i + 1
If i > L then Exit Do
Loop

I prefer the second method because it keeps
all the business of the loop in the loop, so
I find it easier to read. But the first version
is probably a miniscule fraction faster.

You do need to watch out for the quirky behavior
of Do and For, though. Notice that the code above
shows 7. It doesn't exit the loop when you call
Exit Do. It exits at the end of the loop, which is
counterintuitive.

For / Next is even worse:

s = "abc"

For i = 1 to Len(s)
'--whatever
Next
MsgBox i

That code should show a msgbox with "3", since
3 was the last value for i, but it adds 1 to i when
it exits the loop, showing a result of "4"! That can be
slightly handy for checking whether a loop finished:

s = "ab"
For i = 1 to Len(s)
If mid(s, i, 1) = "b" Then Exit For
Next
MsgBox i

i will return 2 here. But if "b" were
not in the string then i would return 3. It kind of
makes sense as a way to design the For / Next loop,
but I find it so confusing, and so misleading when
one goes back later to read the code, that I prefer
to design things so that I'm not depending on the
value of i at all. Some people will think that's silly,
but those little issues are far less important than
being able to easily read your own code next month,
after you've forgotten it.

>
> I've been instructed by a dot net / asp programmer that Exit Do is not a
> great way to end a loop.
>
> Can someone explain to me if this is so, or does this only apply to higher
> level programming languages ?
>
> I am using nested loops and need to exit out of one loop into another for
> something to apply. Any other functional ways of doing this ?
>
> Cheers,
>
>
>
>
>

Richard
Sat Mar 22 12:06:09 CDT 2008


"Robbie Flower" <rflower@hotmail.com> wrote in message
news:104f6a3f1b8e8ca5a85f8127d1a@msnews.microsoft.com...
>
> I've been instructed by a dot net / asp programmer that Exit Do is not a
> great way to end a loop.
>
> Can someone explain to me if this is so, or does this only apply to higher
> level programming languages ?
>
> I am using nested loops and need to exit out of one loop into another for
> something to apply. Any other functional ways of doing this ?
>
> Cheers,
>
>

I agree that Exit Do statements are fine. Same for Exit For, Exit Sub, and
Exit Function. They are much better than GoTo statements (which aren't
allowed). I personally prefer them to conditional statements because they
are easier to read.

--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--

Anthony
Sun Mar 23 17:09:13 CDT 2008

"Robbie Flower" <rflower@hotmail.com> wrote in message
news:104f6a3f1b8e8ca5a85f8127d1a@msnews.microsoft.com...
>
> I've been instructed by a dot net / asp programmer that Exit Do is not a
> great way to end a loop.
>
> Can someone explain to me if this is so, or does this only apply to higher
> level programming languages ?
>
> I am using nested loops and need to exit out of one loop into another for
> something to apply. Any other functional ways of doing this ?
>

As with all things its best to consider sticking with good sound principles
rather than making rules. Exit Do/For/Function/Sub has its uses but it also
has its abuses.

Indescriminate use of Exits can make it difficult to determine under what
conditions a particular block of code will end early. Also use of Exits can
make code more difficult to modify and/or lead to bugs later on.

For example:-

Begin enumerating items
Do Until finished enumeration items
Code stage A
If Some Reason to stop loop then Exit Do
Code Stage B
Loop

In this code stage B is not be executed if there is a reason to exit the
loop. What happens if a developer comes along 6 months later and adds some
code to the loop prior to stage A that allocates a resource that needs to be
expicitly released? It could be easy to miss the exit do in the existing
code and simply add the releasing code after stage B. That would be a bug.

On the other you can find yourself jumping through all sorts of hoops trying
to get execution of a loop to the end of the construct in order to avoid
using an Exit. In which case this is also just as likely to lead to bugs
and readability problems.

Therefore I would avoid Exits if the loop remains reasonably readable. If
Exits are needed make them really, really obvious.

A good example where Exits would be useful, even expected, is in a search
loop. The loop enumerates a set so it will end when the set is consumed.
However it is expected that once a specific item is found it will end there
and then. These loops tend to be simple and the presence of the exit is
obvious.


--
Anthony Jones - MVP ASP/ASP.NET

Todd
Mon Mar 24 00:57:46 CDT 2008

Anthony Jones wrote:
> Robbie Flower wrote:
>>
>> I've been instructed by a dot net / asp programmer that Exit Do is
>> not a great way to end a loop.
>>
>> Can someone explain to me if this is so, or does this only apply to
>> higher level programming languages ?
>>
>> I am using nested loops and need to exit out of one loop into
>> another for something to apply. Any other functional ways of doing
>> this ?
>>
>
> As with all things its best to consider sticking with good sound
> principles rather than making rules. Exit Do/For/Function/Sub has
> its uses but it also has its abuses.
>
> Indescriminate use of Exits can make it difficult to determine under
> what conditions a particular block of code will end early. Also use
> of Exits can make code more difficult to modify and/or lead to bugs
> later on.
>
> For example:-
>
> Begin enumerating items
> Do Until finished enumeration items
> Code stage A
> If Some Reason to stop loop then Exit Do
> Code Stage B
> Loop
>
> In this code stage B is not be executed if there is a reason to exit
> the loop. What happens if a developer comes along 6 months later and
> adds some code to the loop prior to stage A that allocates a resource
> that needs to be expicitly released? It could be easy to miss the
> exit do in the existing code and simply add the releasing code after
> stage B. That would be a bug.
>
> On the other you can find yourself jumping through all sorts of hoops
> trying to get execution of a loop to the end of the construct in
> order to avoid using an Exit. In which case this is also just as
> likely to lead to bugs and readability problems.
>
> Therefore I would avoid Exits if the loop remains reasonably
> readable. If Exits are needed make them really, really obvious.
>
> A good example where Exits would be useful, even expected, is in a
> search loop. The loop enumerates a set so it will end when the set
> is consumed. However it is expected that once a specific item is
> found it will end there and then. These loops tend to be simple and
> the presence of the exit is obvious.

Unfortunatly, your reason/example is too vague to provide any worthwhile
value. A developer who comes along 6 months later and introduces a bug by
making modifications is the direct cause of the bug, not the original
developers' EXIT usage which worked properly prior to modifications.

IMO, what you have described above is an unjustified excuse to blame a
previous developer for incompetent modifications.

'Modification 6 months later (as described above)
Begin enumerating items
Do Until finished enumeration items
Modification requiring a resource release
Code stage A
If Some Reason to stop loop then
Modification to release resource
Exit Do
End If
Code Stage B
Loop

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

Anthony
Mon Mar 24 17:07:30 CDT 2008

"Todd Vargo" <tlvargo@sbcglobal.netz> wrote in message
news:uOyPeWXjIHA.6032@TK2MSFTNGP03.phx.gbl...
> Anthony Jones wrote:
> > Robbie Flower wrote:
> >>
> >> I've been instructed by a dot net / asp programmer that Exit Do is
> >> not a great way to end a loop.
> >>
> >> Can someone explain to me if this is so, or does this only apply to
> >> higher level programming languages ?
> >>
> >> I am using nested loops and need to exit out of one loop into
> >> another for something to apply. Any other functional ways of doing
> >> this ?
> >>
> >
> > As with all things its best to consider sticking with good sound
> > principles rather than making rules. Exit Do/For/Function/Sub has
> > its uses but it also has its abuses.
> >
> > Indescriminate use of Exits can make it difficult to determine under
> > what conditions a particular block of code will end early. Also use
> > of Exits can make code more difficult to modify and/or lead to bugs
> > later on.
> >
> > For example:-
> >
> > Begin enumerating items
> > Do Until finished enumeration items
> > Code stage A
> > If Some Reason to stop loop then Exit Do
> > Code Stage B
> > Loop
> >
> > In this code stage B is not be executed if there is a reason to exit
> > the loop. What happens if a developer comes along 6 months later and
> > adds some code to the loop prior to stage A that allocates a resource
> > that needs to be expicitly released? It could be easy to miss the
> > exit do in the existing code and simply add the releasing code after
> > stage B. That would be a bug.
> >
> > On the other you can find yourself jumping through all sorts of hoops
> > trying to get execution of a loop to the end of the construct in
> > order to avoid using an Exit. In which case this is also just as
> > likely to lead to bugs and readability problems.
> >
> > Therefore I would avoid Exits if the loop remains reasonably
> > readable. If Exits are needed make them really, really obvious.
> >
> > A good example where Exits would be useful, even expected, is in a
> > search loop. The loop enumerates a set so it will end when the set
> > is consumed. However it is expected that once a specific item is
> > found it will end there and then. These loops tend to be simple and
> > the presence of the exit is obvious.
>
> Unfortunatly, your reason/example is too vague to provide any worthwhile
> value. A developer who comes along 6 months later and introduces a bug by
> making modifications is the direct cause of the bug, not the original
> developers' EXIT usage which worked properly prior to modifications.
>
> IMO, what you have described above is an unjustified excuse to blame a
> previous developer for incompetent modifications.
>
> 'Modification 6 months later (as described above)
> Begin enumerating items
> Do Until finished enumeration items
> Modification requiring a resource release
> Code stage A
> If Some Reason to stop loop then
> Modification to release resource
> Exit Do
> End If
> Code Stage B
> Loop
>

The code above is broken can you see why?

Its not about assigning blame to anyone. Its about realising that coding is
only 20% communicating with a computer and 80% communicating with humans
(include a 6 month in future version of yourself). Humans _are_ prone to
error. The goal is to reduce the errors, not simply avoiding being the one
blamed for the errors. Anything you can do when writing code that can avoid
future potential bugs (whilst not increasing the risk of introducing bugs in
the present) is a good thing.

Burying additional exit points _are_ a source of bugs, whether you cause
them or some other 'incompetent' programmer causes them.

According to your criteria I must be an 'incompetent' programmer. I'm sure
at some point I've modified code that I thought I understood only for it to
fail when I tested it. Tell me you've never modified an existing piece of
code and it fail the first time you run it through? In many cases I've had
to modify code that leaves a lot to be desired for clarity and its wasted a
lot of my time when the effort to make the code clearer would have been
minimal. Does the fact that the original code works of itself prove
competancy?

I think gave a fair and balanced view. IMO, additional exits may be a
necessary evil and in some case they may even be the most elegant and
expected solution. However if they can be reasonably avoided they should.

--
Anthony Jones - MVP ASP/ASP.NET

Todd
Tue Mar 25 19:17:04 CDT 2008


"Anthony Jones" <Ant@yadayadayada.com> wrote in message
news:uuOo1tfjIHA.3740@TK2MSFTNGP04.phx.gbl...
> "Todd Vargo" <tlvargo@sbcglobal.netz> wrote in message
> news:uOyPeWXjIHA.6032@TK2MSFTNGP03.phx.gbl...
> > Anthony Jones wrote:
> > > Robbie Flower wrote:
> > >>
> > >> I've been instructed by a dot net / asp programmer that Exit Do is
> > >> not a great way to end a loop.
> > >>
> > >> Can someone explain to me if this is so, or does this only apply to
> > >> higher level programming languages ?
> > >>
> > >> I am using nested loops and need to exit out of one loop into
> > >> another for something to apply. Any other functional ways of doing
> > >> this ?
> > >>
> > >
> > > As with all things its best to consider sticking with good sound
> > > principles rather than making rules. Exit Do/For/Function/Sub has
> > > its uses but it also has its abuses.
> > >
> > > Indescriminate use of Exits can make it difficult to determine under
> > > what conditions a particular block of code will end early. Also use
> > > of Exits can make code more difficult to modify and/or lead to bugs
> > > later on.
> > >
> > > For example:-
> > >
> > > Begin enumerating items
> > > Do Until finished enumeration items
> > > Code stage A
> > > If Some Reason to stop loop then Exit Do
> > > Code Stage B
> > > Loop
> > >
> > > In this code stage B is not be executed if there is a reason to exit
> > > the loop. What happens if a developer comes along 6 months later and
> > > adds some code to the loop prior to stage A that allocates a resource
> > > that needs to be expicitly released? It could be easy to miss the
> > > exit do in the existing code and simply add the releasing code after
> > > stage B. That would be a bug.
> > >
> > > On the other you can find yourself jumping through all sorts of hoops
> > > trying to get execution of a loop to the end of the construct in
> > > order to avoid using an Exit. In which case this is also just as
> > > likely to lead to bugs and readability problems.
> > >
> > > Therefore I would avoid Exits if the loop remains reasonably
> > > readable. If Exits are needed make them really, really obvious.
> > >
> > > A good example where Exits would be useful, even expected, is in a
> > > search loop. The loop enumerates a set so it will end when the set
> > > is consumed. However it is expected that once a specific item is
> > > found it will end there and then. These loops tend to be simple and
> > > the presence of the exit is obvious.
> >
> > Unfortunatly, your reason/example is too vague to provide any worthwhile
> > value. A developer who comes along 6 months later and introduces a bug
by
> > making modifications is the direct cause of the bug, not the original
> > developers' EXIT usage which worked properly prior to modifications.
> >
> > IMO, what you have described above is an unjustified excuse to blame a
> > previous developer for incompetent modifications.
> >
> > 'Modification 6 months later (as described above)
> > Begin enumerating items
> > Do Until finished enumeration items
> > Modification requiring a resource release
> > Code stage A
> > If Some Reason to stop loop then
> > Modification to release resource
> > Exit Do
> > End If
> > Code Stage B
> > Loop
> >
>
> The code above is broken can you see why?
>
> Its not about assigning blame to anyone. Its about realising that coding
is
> only 20% communicating with a computer and 80% communicating with humans
> (include a 6 month in future version of yourself). Humans _are_ prone to
> error. The goal is to reduce the errors, not simply avoiding being the
one
> blamed for the errors. Anything you can do when writing code that can
avoid
> future potential bugs (whilst not increasing the risk of introducing bugs
in
> the present) is a good thing.
>
> Burying additional exit points _are_ a source of bugs, whether you cause
> them or some other 'incompetent' programmer causes them.
>
> According to your criteria I must be an 'incompetent' programmer. I'm
sure
> at some point I've modified code that I thought I understood only for it
to
> fail when I tested it. Tell me you've never modified an existing piece of
> code and it fail the first time you run it through? In many cases I've
had
> to modify code that leaves a lot to be desired for clarity and its wasted
a
> lot of my time when the effort to make the code clearer would have been
> minimal. Does the fact that the original code works of itself prove
> competancy?
>
> I think gave a fair and balanced view. IMO, additional exits may be a
> necessary evil and in some case they may even be the most elegant and
> expected solution. However if they can be reasonably avoided they should.

It is said... "there is no such thing as a dumb question"...

...I have never believed this statement to be 100% true.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)