Visual Basic - GOTO Exit

Author

GOTO Exit

101

2005-04-26, 3:55 am

Comming from a COBOL environment, GOTO Exit created unstructered code and
was not considered to be a good practice. Is the same true with Exit Select,
Exit Sub, Exit Function, ....... ?

Bob Butler

2005-04-26, 3:55 am

"101" <AceMagoo61@yahoo.com> wrote in message
news:Cggbe.413$jS6.219@trndny06
> Comming from a COBOL environment, GOTO Exit created unstructered code
> and was not considered to be a good practice. Is the same true with
> Exit Select, Exit Sub, Exit Function, ....... ?

Opinions will vary and it's basically a matter of style. I'd guess that
most people would find them less distasteful than GOTO but I generally try
to minimize using them, if not avoid them outright. I've found that in a
lot of cases where I'm tempted to use them it's better to redesign the
procedure and possibly split it into multiple procedures. That said, the
most common use I make of them is to skip out of procedures immediately as
in:

Public Sub DoSomething()
If test1 Or test2 Then Exit Sub
' more complex code here; usually with several nested IF statements
End Sub

In that case it's usually just to avoid adding another nesting level or two.

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

Larry Serflaten

2005-04-26, 3:55 am

"101" <AceMagoo61@yahoo.com> wrote
> Comming from a COBOL environment, GOTO Exit created unstructered code and
> was not considered to be a good practice. Is the same true with Exit Select,
> Exit Sub, Exit Function, ....... ?

Do you really want to be concerned about the minute details of
'good practise' programming, or would you rather get the job done
with mimimal execution?

'Good practise' would suggest you have only one entry point, and
one exit point from any procedure. But I'd think any code that is
easily understood and easy to maintain is fair game!

Typically that means input validation test, recursion tests, and the like
that are done at the start of a procedure, are likely candidates to trigger
an Exit. I'd suggest that Exit commands buried deep inside the procedure
should be avoided except in specifically designed and notated recursive
routines.

But all that falls under a broader category of personal style. Who's to say
which is the better approach?

LFS

MikeD

2005-04-26, 3:55 am

"101" <AceMagoo61@yahoo.com> wrote in message
news:Cggbe.413$jS6.219@trndny06...
> Comming from a COBOL environment, GOTO Exit created unstructered code and
> was not considered to be a good practice. Is the same true with Exit
Select,
> Exit Sub, Exit Function, ....... ?

Depends on how you use them. *Anything* in a programming language can be
misused or abused. For example, most programmers would agree that an
over-abundant use of global variables would not be considered "good
practice". That doesn't mean global variables themselves are bad, though.
What it means is that a variable should only be global if it truly needs to
be global. It's rare that this is ever the case as there are usually better
options. In that same sense, writing a bunch of If Then statements that Exit
Sub might not be the best approach. Nested If Then statements *might* be
better. But, it always needs to be considered on a case-by-case basis.

Before going any further, VB6 and under have no such thing as an Exit
Select, so you must be talking about VB.NET. This newsgroup is for VB6 and
under. Any discussion or advice you want regarding VB.NET should be asked in
a newsgroup with "dotnet" in the name.

--
Mike
Microsoft MVP Visual Basic

Charles Krug

2005-04-26, 3:56 pm

"101" <AceMagoo61@yahoo.com> wrote in message
news:Cggbe.413$jS6.219@trndny06
> Comming from a COBOL environment, GOTO Exit created unstructered code
> and was not considered to be a good practice. Is the same true with
> Exit Select, Exit Sub, Exit Function, ....... ?
>

What's most important is that the intent of the code is clear.

Sometimes, we make out code go through odd contortions in the name of
being "well structured" which makes our code harder than it needs to be
to read.

I've quite a few button functions that have a "Do nothing" case. I've
two choices:

1. test for the do nothing case and return

2. test for the negation of the do nothing case and execute.

Very often, option 1 is easier to read.

So long as the code is clear, don't get too hung up on the specifics of
style.

Paul Clement

2005-04-26, 3:56 pm

On Tue, 26 Apr 2005 00:51:46 GMT, "101" <AceMagoo61@yahoo.com> wrote:

¤ Comming from a COBOL environment, GOTO Exit created unstructered code and
¤ was not considered to be a good practice. Is the same true with Exit Select,
¤ Exit Sub, Exit Function, ....... ?
¤

Matter of preference. I've done both. However, if you have many exit points in a Sub or Function the
code can be difficult to debug and maintain. With GoTo, flow of code execution should occur in a
single direction. Branching back to code in a Sub or Function should be avoided.

Paul
~~~~
Microsoft MVP (Visual Basic)

Tony Proctor

2005-04-28, 8:55 am

Consider it another code-structure paradigm. Classic structured programming
only admitted loops, If..Then..Else, Case statements, and of course
procedures. Goto's are generally frowned upon because you can easily create
spaghetti code with them. These more-limited branch statements only go in a
forwards direction, and only to the end of a named enclosing statement.
Hence, although they're still effectively Goto statements, they're a lot
more restrained. I think I first came across them in Bliss (DEC's
proprietary SIL).

You can consider structured exception handling to be another type of
restrained Goto. If an exception thrown by a low-level procedure is caught
by the handler declared in a higher-level one, then the stack is unwound and
control transferred to that handler. It's still a type of cross-procedure
Goto, but the semantics are strict . However, VB's intra-procedure exception
handling, as opposed to this inter-procedure exception handling, leaves
something to be desired because you can create spaghetti code with
On..Error..Goto and Resume statements. This is why VB.Net introduced
Try..Catch blocks

They're all designed to be controlled extensions to the classic structured
code paradigm. In other words, providing the programmer with more tools and
conveniences, but while still keeping some coherent structure to the code.

Tony Proctor

"101" <AceMagoo61@yahoo.com> wrote in message
news:Cggbe.413$jS6.219@trndny06...
> Comming from a COBOL environment, GOTO Exit created unstructered code and
> was not considered to be a good practice. Is the same true with Exit
Select,
> Exit Sub, Exit Function, ....... ?
>
>

Sponsored Links