what is wrong with the goto command?

[WindAndWaves]

Can anyone tell me what is wrong with the goto command. I noticed it is one
of those NEVER USE.

I can understand that it may lead to confusing code, but I often use it like
this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function
---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Salad]

WindAndWaves wrote:

Can anyone tell me what is wrong with the goto command. I noticed it is one
of those NEVER USE.

I can understand that it may lead to confusing code, but I often use it like
this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function

I operate under the theory that an ugly system that works is better than
a pretty system that doesn't. If it works for you and you are happy as
a clam, then go ahead.

That being said, if I were to hire someone that coded that way I would
give him/her one warning and the second time I saw him/her code like
that I would fire that person.

Also, if I were to come in behind the person that got fired I would most
likely update the code unless it was an irrelevent part of the system or
would take too much time to correct in regards to the benefits.

But there is nothing wrong with it...if you are talking about the
process itself working.

I think it shows a lack of pride. It shows you don't care. It shows
you are a maverick, not a team player. It shows you like spaghetti, the
messier the better, lots of tomato stains on your shirt, pants, and the
floor. Other programmers that study your code will wonder how you got
the job. Most likely your coworker programmers will laugh at you behind
your back and your coding style will remind them of the movie The Good,
The Bad, The Ugly.

But it works. If your application is of no consequence, use it.

Just my $.02

[WindAndWaves]

Dear Caesar Salad

You made me laugh. But you never really told me what is wrong with it.

In my example, it seems to me that I make the code easier, not harder to
understand, by breaking it up into parts. You read the main code to get the
gist of things and if you are interested then you can check on the
individual sub-routines. Some of these sub-routines may be lengthy and
would get in the way?

I mean, how would you write a function like the one I put below???

I definitely am a maverick, but that is not necessarily a bad thing (I
hope). Here in NZ we like to do things our own way.

Thanks for your reply

Nicolaas


"Salad" <oi*@vinegar.com> wrote in message
news:j5*******************@newsread1.news.pas.eart hlink.net...

WindAndWaves wrote:

Can anyone tell me what is wrong with the goto command. I noticed it is one of those NEVER USE.

I can understand that it may lead to confusing code, but I often use it like this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function

I operate under the theory that an ugly system that works is better than
a pretty system that doesn't. If it works for you and you are happy as
a clam, then go ahead.

That being said, if I were to hire someone that coded that way I would
give him/her one warning and the second time I saw him/her code like
that I would fire that person.

Also, if I were to come in behind the person that got fired I would most
likely update the code unless it was an irrelevent part of the system or
would take too much time to correct in regards to the benefits.

But there is nothing wrong with it...if you are talking about the
process itself working.

I think it shows a lack of pride. It shows you don't care. It shows
you are a maverick, not a team player. It shows you like spaghetti, the
messier the better, lots of tomato stains on your shirt, pants, and the
floor. Other programmers that study your code will wonder how you got
the job. Most likely your coworker programmers will laugh at you behind
your back and your coding style will remind them of the movie The Good,
The Bad, The Ugly.

But it works. If your application is of no consequence, use it.

Just my $.02

---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Stewart Allen]

Hi Nicolaas

The way you've written your code is like a bit of spaghetti, all over the
place within the same sub/function routine. If your one: two: & three:
labels contain complex code or many lines it would pay to create separate
subs/functions and call those subs/functions from the case one etc. This way
they can be tested and modified completely separately from the main
sub/function and the flow of the executed code follows a logical path, top
to bottom, not top to bottom then exit out the middle. My example below:

Function x
Select Case z
Case one
Call Subby1(z)
Case two
t = Fun2(z)
Case 3
t = Fun3(z)
End Select
x = t
ExitFun:
Exit Function
ErrTrap:
MsgBox "?????"
Resume ExitFun
End Function

Sub Subby1(e)
.....
.....
End Sub

Function Fun2(g) As Whatever
i = g * 3
Fun2 = i
End Function

Function Fun3(p) As Whatever
y = p * 6
Fun3 = y
End Function

If you're only going to have a few lines of code to execute for each Case
condition, place them under the Case conditions.
Try to follow the flow of this example using your logic (some obvious lines
omitted):
Sub Temp
Do Until rst.EOF
.MoveFirst
Select Case rst!City
Case "Auckland"
goto one
Case "Christchurch"
goto two
Case "Wellington"
goto three
End Select
.MoveNext
Loop
TempExit:
Exit Sub
One:
MsgBox "City of Sails"
Two:
MsgBox "Smog City"
Three:
MsgBox "Windy City"
End Sub

I haven't tested the above code but will try it tonight.

Stewart
"WindAndWaves" <ac****@ngaru.com> wrote in message
news:bt******************@news.xtra.co.nz...

Dear Caesar Salad

You made me laugh. But you never really told me what is wrong with it.

In my example, it seems to me that I make the code easier, not harder to
understand, by breaking it up into parts. You read the main code to get the gist of things and if you are interested then you can check on the
individual sub-routines. Some of these sub-routines may be lengthy and
would get in the way?

I mean, how would you write a function like the one I put below???

I definitely am a maverick, but that is not necessarily a bad thing (I
hope). Here in NZ we like to do things our own way.

Thanks for your reply

Nicolaas


"Salad" <oi*@vinegar.com> wrote in message
news:j5*******************@newsread1.news.pas.eart hlink.net...

WindAndWaves wrote:

Can anyone tell me what is wrong with the goto command. I noticed it

is

one of those NEVER USE.

I can understand that it may lead to confusing code, but I often use

it

like this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function

I operate under the theory that an ugly system that works is better than
a pretty system that doesn't. If it works for you and you are happy as
a clam, then go ahead.

That being said, if I were to hire someone that coded that way I would
give him/her one warning and the second time I saw him/her code like
that I would fire that person.

Also, if I were to come in behind the person that got fired I would most
likely update the code unless it was an irrelevent part of the system or
would take too much time to correct in regards to the benefits.

But there is nothing wrong with it...if you are talking about the
process itself working.

I think it shows a lack of pride. It shows you don't care. It shows
you are a maverick, not a team player. It shows you like spaghetti, the
messier the better, lots of tomato stains on your shirt, pants, and the
floor. Other programmers that study your code will wonder how you got
the job. Most likely your coworker programmers will laugh at you behind
your back and your coding style will remind them of the movie The Good,
The Bad, The Ugly.

But it works. If your application is of no consequence, use it.

Just my $.02

---
Please immediately let us know (by phone or return email) if (a) this

email contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[WindAndWaves]

Thank you stewart. I really appreciate your comments.
---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Stewart Allen]

I've tried out the last bit of code I sent you; when using the goto label
from within a loop you can't get back into the loop.

Stewart

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:8H******************@news.xtra.co.nz...

Thank you stewart. I really appreciate your comments.
---
Please immediately let us know (by phone or return email) if (a) this email contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[WindAndWaves]

what do you mean???

from within a loop you can't get back into the loop.

---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Salad]

WindAndWaves wrote:

Dear Caesar Salad

You made me laugh. But you never really told me what is wrong with it.
I'm glad you laughed.

There is nothing wrong with with the code. It works. In programming,
that is the bottom line...creating something that works.

However, your code examples is called spaghetti code. Spaghetti is a
bunch of noodles swimming around on a plate usually with some topping.
The start and end of the noodles may not be easy to see.

In days past, people used GoTo a lot. Yours is a very simple example.
However, lets say that you wanted to create more GoTos in the GoTos.
All of a sudden you've added complexity to the subroutine. And if you
add GoTos in those GoTos all of a sudden you have a mess. Then you if
you have a problem you are jumping all over the routine trying to figure
out what's what.

That is why there are functions and procedures. You can break a task
into segments and return values or performs some process. It adds
readability to the program. It may help in debugging.

Your code example is small. Remember that. But it would be very easy
to expand it so that it would be difficult to follow. In a routine you
want to see the start, the process, and the end in easy or as-easy to
follow increments as you can.

You don't want to come back to this code later on and cry "Holy Smoke,
what the heck is that?"

In my example, it seems to me that I make the code easier, not harder to
understand, by breaking it up into parts. You read the main code to get the
gist of things and if you are interested then you can check on the
individual sub-routines. Some of these sub-routines may be lengthy and
would get in the way?

I mean, how would you write a function like the one I put below???
Stewart gave a good example.

I definitely am a maverick, but that is not necessarily a bad thing (I
hope). Here in NZ we like to do things our own way.

I think most good programmers are mavericks. The thing is that you
don't want to get so far away from the herd (newsgroup help responders)
you're alone in the hot desert and the water hole is a mirage (newsgroup
responders provide no help or answers).

If this is a personal program that only you will ever work on, then do
what you want. Nobody will laugh. Nobody will cry "Why ME!" Any
arbitrary rules can be broken. The goal is to create something that
works. If you plan on passing on this app to a subordinate in the
future due to a promotion or perhaps take another job or even go on to
another project before you retire, it is worthwhile to develop good
habits now.

[Stewart Allen]

Create a table called tblCities and add 6 cities where three of them must be
Auckland, Christchurch and Wellington and paste the following code into a
standard module:

Sub Temp()
Dim db As DAO.Database
Dim rst As DAO.Recordset
Set db = CurrentDb
Set rst = db.OpenRecordset("tblCities")
With rst
.MoveFirst
Do Until .EOF
Select Case !City
Case "Auckland"
GoTo One
Case "Christchurch"
GoTo Two
Case "Wellington"
GoTo Three
Case Else
GoTo Four
End Select
.MoveNext
Loop
End With
One:
MsgBox "City of Sails"
Two:
MsgBox "Smog City"
Three:
MsgBox "Windy City"
Four:
MsgBox "Unknown nickname"
Temp_Exit:
On Error Resume Next
rst.Close
Set rst = Nothing
Set db = Nothing
Exit Sub
Temp_Err:
MsgBox Err.Number & " " & Err.Description, vbInformation, "Temp Error"
Resume Temp_Exit
End Sub

Place a break point on the line starting With rst by placing your cursor on
that line and press <F9>. Open up the immediate window (Ctrl + G) and run
the routine by typing Temp and pressing <Enter>. Press <F8> to follow the
code line by line and you'll see that when you exit the loop using the goto
command you won't get back into it again. If you have 6 records (Cities) you
should go through the Do Until Loop 6 times and have 6 MsgBox's appear.

Stewart
"WindAndWaves" <ac****@ngaru.com> wrote in message
news:UY******************@news.xtra.co.nz...

what do you mean???

from within a loop you can't get back into the loop.
---
Please immediately let us know (by phone or return email) if (a) this

email contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Steve Jorgensen]

On Mon, 7 Jun 2004 14:03:41 +1200, "WindAndWaves" <ac****@ngaru.com> wrote:

Can anyone tell me what is wrong with the goto command. I noticed it is one
of those NEVER USE.

All of the previous replies are great, but I also wanted to add that the truth
is Gotos are things you should mostly avoid, but they can be used well in very
specific circumstances, and with proper consideration. Use them only when
there's a good reason to do so, and where they don't add complexity or
increase the likelihood of unwanted side-effects creeping into the code.

An example of a good way to use Gotos is to skip the majority of a procedure
when it would be irrelevant. A Goto, when used in this way, is known as a
Guard Clause. The alternative is to nest the majority of the procedure in an
If block, and if there are several of them, the body of the code may be nested
several levels deep.

Without guard clauses...
Sub Foo(colBar As VBA.Collection)
If Not (objBar Is Nothing) Then
If objBar.Count > 0 Then
If objBar(1) <> "-" Then
' Code body
' ...
' ...
' ...
End If
End If
End If
' Clean-up code.
' ...
End Sub

With guard clauses...
Sub Foo(colBar As VBA.Collection)
If objBar Is Nothing Then Goto Clean_Up_And_Exit
If objBar.Count = 0 Then Goto Clean_Up_And_Exit
If objBar(1) = "-" Then Goto Clean_Up_And_Exit
' Code body
' ...
' ...
' ...
Clean_Up_And_Exit:
' Clean-up code.
' ...
End Sub

[Edward]

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<8t********************************@4ax.com>. ..

On Mon, 7 Jun 2004 14:03:41 +1200, "WindAndWaves" <ac****@ngaru.com> wrote:

Can anyone tell me what is wrong with the goto command. I noticed it is one
of those NEVER USE.

All of the previous replies are great, but I also wanted to add that the truth
is Gotos are things you should mostly avoid, but they can be used well in very
specific circumstances, and with proper consideration. Use them only when
there's a good reason to do so, and where they don't add complexity or
increase the likelihood of unwanted side-effects creeping into the code.

An example of a good way to use Gotos is to skip the majority of a procedure
when it would be irrelevant. A Goto, when used in this way, is known as a
Guard Clause. The alternative is to nest the majority of the procedure in an
If block, and if there are several of them, the body of the code may be nested
several levels deep.

Without guard clauses...
Sub Foo(colBar As VBA.Collection)
If Not (objBar Is Nothing) Then
If objBar.Count > 0 Then
If objBar(1) <> "-" Then
' Code body
' ...
' ...
' ...
End If
End If
End If
' Clean-up code.
' ...
End Sub

With guard clauses...
Sub Foo(colBar As VBA.Collection)
If objBar Is Nothing Then Goto Clean_Up_And_Exit
If objBar.Count = 0 Then Goto Clean_Up_And_Exit
If objBar(1) = "-" Then Goto Clean_Up_And_Exit
' Code body
' ...
' ...
' ...
Clean_Up_And_Exit:
' Clean-up code.
' ...
End Sub

Sorry, but this is a mess.

' Make scope explicit
Public Sub Foo(colBar As VBA.Collection)

' This is the one place in all my code that I ever have a GoTo
On Error GoTo FooErr

If ((objBar Is Nothing) Or (objBar.Count = 0) Or (objBar(1) = "-")) Then
' Do your Clean Up And Exit stuff here
Else
' Code body
' ...
' ...
' ...
EndIf

CleanUpAndExit:
' Clean-up code.
' ...
FooErr:
' Error Handling
Resume CleanUpAndExit
End Sub

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

[WindAndWaves]

thanks both of you for that. I must say, it looks great and I agree with
both

It was indeed a bit shorter with Edwards code, but not necessarily easier to
understand for me.

I learned from both examples though. Great Thanks

---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 06/06/2004

[rkc]

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:D2******************@news.xtra.co.nz...

Can anyone tell me what is wrong with the goto command. I noticed it is one of those NEVER USE.

If you are as interested in learning to program as you appear to be
(your enthusiasm is a breath of fresh air) than I would urge you to
buy, beg or borrow a copy of the book Code Complete by Steve
McConnell. I really think that once you start reading it, you won't
put it down for more than a couple of minutes at a time before you
want to pick it up again.

[WindAndWaves]

I will definitely have a look for it.

Thank you.
---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 06/06/2004

[Steve Jorgensen]

On Mon, 7 Jun 2004 22:51:27 +1200, "WindAndWaves" <ac****@ngaru.com> wrote:

thanks both of you for that. I must say, it looks great and I agree with
both

It was indeed a bit shorter with Edwards code, but not necessarily easier to
understand for me.

Unfortunately, no disrespect to Edward, but he's wrong. See my reply to
Edward.

[Steve Jorgensen]

On 7 Jun 2004 03:36:58 -0700, te********@hotmail.com (Edward) wrote:

....

An example of a good way to use Gotos is to skip the majority of a procedure
when it would be irrelevant. A Goto, when used in this way, is known as a
Guard Clause. The alternative is to nest the majority of the procedure in an
If block, and if there are several of them, the body of the code may be nested
several levels deep.

Without guard clauses...
Sub Foo(colBar As VBA.Collection)
If Not (objBar Is Nothing) Then
If objBar.Count > 0 Then
If objBar(1) <> "-" Then
' Code body
' ...
' ...
' ...
End If
End If
End If
' Clean-up code.
' ...
End Sub

With guard clauses...
Sub Foo(colBar As VBA.Collection)
If objBar Is Nothing Then Goto Clean_Up_And_Exit
If objBar.Count = 0 Then Goto Clean_Up_And_Exit
If objBar(1) = "-" Then Goto Clean_Up_And_Exit
' Code body
' ...
' ...
' ...
Clean_Up_And_Exit:
' Clean-up code.
' ...
End Sub

Sorry, but this is a mess.

' Make scope explicit
Public Sub Foo(colBar As VBA.Collection)

' This is the one place in all my code that I ever have a GoTo
On Error GoTo FooErr

If ((objBar Is Nothing) Or (objBar.Count = 0) Or (objBar(1) = "-")) Then
' Do your Clean Up And Exit stuff here
Else
' Code body
' ...
' ...
' ...
EndIf

CleanUpAndExit:
' Clean-up code.
' ...
FooErr:
' Error Handling
Resume CleanUpAndExit
End Sub

Paraphrasing Einstein - make the code as simple as possible, but no simpler.
Your code will not work, and in languages where it does work, it's not
self-documenting.

Notice that each of the conditions will fail with an error if executed in the
wrong context. That's why the prior check must be done separately. In some
languages, the language can short circuit logic and skip conditions that are
not necessary to check based on the previous condition in an And/Or expression
which would keep this code from failing. If you use short circuiting that
way, though, you are not expressing the dependencies, and someone (possibly
you) trying to read the code later is likely to change the order of operations
or insert a new condition in the wrong place, and break it.

Finally, I don't agree that multiple conditions (more than 1 or 2) should be
run together in one statement/line because it's harder to visually parse them
out. Even if they're in one If statement, put line continuations in, and get
the conditions onto separate lines.

Example:

If <condition1> Or _
<condition2> Or _
<condition3> _
Then
' Do stuff
End If

Again, don't even do this in a guard clause case, though. A guard clause is
used when the next piece of code will fail under some condition, and in many
cases, such as my example, guard clauses must protect guard clauses -
sometimes several in a row.

[Steve Jorgensen]

I second the recommendation to read Code Complete. It's a classic, and should
be on every programmer's bookshelf.

On Mon, 7 Jun 2004 23:34:43 +1200, "WindAndWaves" <ac****@ngaru.com> wrote:

I will definitely have a look for it.

Thank you.
---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 06/06/2004

[David W. Fenton]

te********@hotmail.com (Edward) wrote in
news:25*************************@posting.google.co m:

' This is the one place in all my code that I ever have a GoTo
On Error GoTo FooErr

Well, I think there are specific situations where a GoTo makes
sense, such as a ReTry loop, which you may need to do to wait for
some external condition to be met.

Also, I have used it in situations where I wanted to avoid an
If/Then structure. See the code beneath my signature. In that case,
I could have duplicated code in the error handler instead of jumping
back to the main code body. I'm not sure if I can think of a good
reason for not doing that, except that I'm allergic to duplicating
code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Public Function dbLocal(Optional ysnInitialize As Boolean = True) _
As DAO.Database
' 2003/02/08 DWF added comments to explain it to myself!
' uses GoTos instead of If/Then because:
' error of dbCurrent not being Nothing but dbCurrent being closed
' (3420) would then be jumping back into the middle of an If/Then
' statement
On Error GoTo errHandler
Dim strTest As String

If Not ysnInitialize Then GoTo closeDB

retryDB:
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDb()
End If
' now that we know the db variable is not Nothing,
' test if it's Open
strTest = dbCurrent.Name

exitRoutine:
Set dbLocal = dbCurrent
Exit Function

closeDB:
If Not (dbCurrent Is Nothing) Then
'dbCurrent.close
Set dbCurrent = Nothing
End If
GoTo exitRoutine

errHandler:
Select Case Err.Number
Case 3420 ' Object invalid or no longer set.
Set dbCurrent = Nothing
If ysnInitialize Then
Resume retryDB
Else
Resume closeDB
End If
Case Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error in Global Code.dbLocal()"
Resume exitRoutine
End Select
End Function

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0g********************************@4ax.com:

Again, don't even do this in a guard clause case, though. A guard
clause is used when the next piece of code will fail under some
condition, and in many cases, such as my example, guard clauses
must protect guard clauses - sometimes several in a row.

In the case of your example, the tests are interdependent, and the
second is not valid unless the first was passed successfully, and so
forth.

But I see no reason not to OR them when there is *not* such a
logical dependency.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[R Baumann]

If used JUDICIOUSLY(as stated in the previous posts), there is absolutely
nothing wrong with goto.

I have, on the other hand, seen situations where nested IF/WHILE/etc. had
been so deeply nested and mis-used, that the code was practically impossible
to read. Worse than spaghetti code! And this by "senior" programmers!
Had to rewrite it to break it into manageable chunks. Still run into this
mess every once in a while.

Goto should be a valuable part of your programming arsenal. Don't let
anyone ever tell you differently.

Ruben

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

te********@hotmail.com (Edward) wrote in
news:25*************************@posting.google.co m:

' This is the one place in all my code that I ever have a GoTo
On Error GoTo FooErr

Well, I think there are specific situations where a GoTo makes
sense, such as a ReTry loop, which you may need to do to wait for
some external condition to be met.

Also, I have used it in situations where I wanted to avoid an
If/Then structure. See the code beneath my signature. In that case,
I could have duplicated code in the error handler instead of jumping
back to the main code body. I'm not sure if I can think of a good
reason for not doing that, except that I'm allergic to duplicating
code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Public Function dbLocal(Optional ysnInitialize As Boolean = True) _
As DAO.Database
' 2003/02/08 DWF added comments to explain it to myself!
' uses GoTos instead of If/Then because:
' error of dbCurrent not being Nothing but dbCurrent being closed
' (3420) would then be jumping back into the middle of an If/Then
' statement
On Error GoTo errHandler
Dim strTest As String

If Not ysnInitialize Then GoTo closeDB

retryDB:
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDb()
End If
' now that we know the db variable is not Nothing,
' test if it's Open
strTest = dbCurrent.Name

exitRoutine:
Set dbLocal = dbCurrent
Exit Function

closeDB:
If Not (dbCurrent Is Nothing) Then
'dbCurrent.close
Set dbCurrent = Nothing
End If
GoTo exitRoutine

errHandler:
Select Case Err.Number
Case 3420 ' Object invalid or no longer set.
Set dbCurrent = Nothing
If ysnInitialize Then
Resume retryDB
Else
Resume closeDB
End If
Case Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error in Global Code.dbLocal()"
Resume exitRoutine
End Select
End Function

[Larry Linson]

"WindAndWaves" <ac****@ngaru.com> wrote

Can anyone tell me what is wrong with
the goto command. I noticed it is one
of those NEVER USE.
I am in the "JUDICIOUS USE" camp, but overusing GoTo can give you
terrifically nasty headaches when you have to come back and maintain your
code! Probably the reason most of us avoid suggesting it is because 'way too
many might take end up overusing it. As an alternative to the Select Case
with GoTo, sometimes the GoSub statement (retained, I am sure, just for
backward compatibility) might be useful... it will let you "reenter" a
structure. Here's what Access 2002 Help says about it:

GoSub...Return Statement
Branches to and returns from a subroutine within a procedure.

Syntax

GoSub line
....
line
....

Return

The line argument can be any line label or line number.

Remarks

You can use GoSub and Return anywhere in a procedure, but GoSub and the
corresponding Return statement must be in the same procedure. A subroutine
can contain more than one Return statement, but the first Return statement
encountered causes the flow of execution to branch back to the statement
immediately following the most recently executed GoSub statement.

Note You can't enter or exit Sub procedures with GoSub...Return.

Tip Creating separate procedures that you can call may provide a more
structured alternative to using GoSub...Return.

"WindAndWaves" <ac****@ngaru.com> wrote
Can anyone tell me what is wrong with
the goto command. I noticed it is one
of those NEVER USE.

[Steve Jorgensen]

On Mon, 07 Jun 2004 18:56:57 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0g********************************@4ax.com :

Again, don't even do this in a guard clause case, though. A guard
clause is used when the next piece of code will fail under some
condition, and in many cases, such as my example, guard clauses
must protect guard clauses - sometimes several in a row.

In the case of your example, the tests are interdependent, and the
second is not valid unless the first was passed successfully, and so
forth.

But I see no reason not to OR them when there is *not* such a
logical dependency.

Oh, I absolutely agree. I'm just saying, for legibility, use line
continuations to break up the conditions vertically if there are very many of
them.

The only times I break up conditions into actual separate If statements are
when they are true Guard Clause conditions, or in the rare case when that
helps with a noticeable performance issue (since VB/VBA don't sort circuit
conditionals).

[Steve Jorgensen]

On Mon, 7 Jun 2004 13:10:17 -0700, "R Baumann" <ry**@9yahoo.com> wrote:

If used JUDICIOUSLY(as stated in the previous posts), there is absolutely
nothing wrong with goto.

I have, on the other hand, seen situations where nested IF/WHILE/etc. had
been so deeply nested and mis-used, that the code was practically impossible
to read. Worse than spaghetti code! And this by "senior" programmers!
Had to rewrite it to break it into manageable chunks. Still run into this
mess every once in a while.

Goto should be a valuable part of your programming arsenal. Don't let
anyone ever tell you differently.

But it is so often misused, that it is sometimes more helpful to teach people
to avoid it altogether first, then tell them when it's OK.

[Edward]

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<0g********************************@4ax.com>. ..

On 7 Jun 2004 03:36:58 -0700, te********@hotmail.com (Edward) wrote: [...]

With guard clauses...
Sub Foo(colBar As VBA.Collection)
If objBar Is Nothing Then Goto Clean_Up_And_Exit
If objBar.Count = 0 Then Goto Clean_Up_And_Exit
If objBar(1) = "-" Then Goto Clean_Up_And_Exit
' Code body
' ...
' ...
' ...
Clean_Up_And_Exit:
' Clean-up code.
' ...
End Sub

Sorry, but this is a mess.

' Make scope explicit
Public Sub Foo(colBar As VBA.Collection)

' This is the one place in all my code that I ever have a GoTo
On Error GoTo FooErr

If ((objBar Is Nothing) Or (objBar.Count = 0) Or (objBar(1) = "-")) Then
' Do your Clean Up And Exit stuff here
Else
' Code body
' ...
' ...
' ...
EndIf

CleanUpAndExit:
' Clean-up code.
' ...
FooErr:
' Error Handling
Resume CleanUpAndExit
End Sub

Paraphrasing Einstein - make the code as simple as possible, but no simpler.
Your code will not work, and in languages where it does work, it's not
self-documenting.

Of course it will work - it's air code.
Notice that each of the conditions will fail with an error if executed in the
wrong context.
Care to expand on that? I don't understand what you mean.
That's why the prior check must be done separately.
What prior check?
In some
languages, the language can short circuit logic and skip conditions that are
not necessary to check based on the previous condition in an And/Or expression
which would keep this code from failing. If you use short circuiting that
way, though, you are not expressing the dependencies, and someone (possibly
you) trying to read the code later is likely to change the order of operations
or insert a new condition in the wrong place, and break it.
What dependencies? I think you've lost the point of this whole
exercise, which was a discussion about the use of GoTo. It wasn't
about the entirely fictitious state of objbar. I don't give a pair of
pyjamas about the state of objbar.
Finally, I don't agree that multiple conditions (more than 1 or 2) should be
run together in one statement/line because it's harder to visually parse them
out.
Not with my brain it isn't.
Even if they're in one If statement, put line continuations in, and get
the conditions onto separate lines.

Example:

If <condition1> Or _
<condition2> Or _
<condition3> _
Then
' Do stuff
End If
Horrible, ugly, unnecessary and error prone. I never use line
continuations except for strings. In any case, this is entirely a
matter of aesthetics, not language usage nor syntactical or logical
correctness.
Again, don't even do this in a guard clause case, though. A guard clause is
used when the next piece of code will fail under some condition, and in many
cases, such as my example, guard clauses must protect guard clauses -
sometimes several in a row.

Is there a typo in your example code? I only ask because the argument
to Foo is "colbar" but you reference "objbar" elsewhere?

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

[aaj]

Hi

This is probably a dumb question, but nothing ventured, nothing gained, do
for next loops use the stack? and if they do would jumping out of a loop
using goto prevent the stack from being cleared i.e.

Private Sub test()
Dim i As Integer
Dim j as integer

For i = 1 To 1000
If some condition Then GoTo exit_here
Next i

jump_in_here:
For j= 1 To 1000
If some condition Then GoTo exit_here
Next i

etc...

End

-------------------
exit_here:
' do things like print warnings and jump back in after the first loop
MsgBox i
MsgBox j
GoTo jump_in_here

End Sub

What I am wondering is if ending the loop doesn't clear the stack, is it
possible that using goto could eventually generate a stack overflow?

I wouldn't do the above and I have no idea if For Next puts things on the
stack, its just out of interest really....

thanks

Andy
"WindAndWaves" <ac****@ngaru.com> wrote in message
news:D2******************@news.xtra.co.nz...

Can anyone tell me what is wrong with the goto command. I noticed it is one of those NEVER USE.

I can understand that it may lead to confusing code, but I often use it like this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function
---
Please immediately let us know (by phone or return email) if (a) this email contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[aaj]

Just an after thought on this,

I guess that if you jumped about using goto statements, it could become
difficult to determine which objects/connections are open, where as
normally, you can ensure everything is set to nothing at the end... I dont
know...I'm just speculating?

"aaj" <a.*@c.com> wrote in message
news:40**********************@news.easynet.co.uk.. .

Hi

This is probably a dumb question, but nothing ventured, nothing gained, do
for next loops use the stack? and if they do would jumping out of a loop
using goto prevent the stack from being cleared i.e.

Private Sub test()
Dim i As Integer
Dim j as integer

For i = 1 To 1000
If some condition Then GoTo exit_here
Next i

jump_in_here:
For j= 1 To 1000
If some condition Then GoTo exit_here
Next i

etc...

End

-------------------
exit_here:
' do things like print warnings and jump back in after the first loop
MsgBox i
MsgBox j
GoTo jump_in_here

End Sub

What I am wondering is if ending the loop doesn't clear the stack, is it
possible that using goto could eventually generate a stack overflow?

I wouldn't do the above and I have no idea if For Next puts things on the
stack, its just out of interest really....

thanks

Andy
"WindAndWaves" <ac****@ngaru.com> wrote in message
news:D2******************@news.xtra.co.nz...

Can anyone tell me what is wrong with the goto command. I noticed it is

one

of those NEVER USE.

I can understand that it may lead to confusing code, but I often use it

like

this:

is this wrong?????

Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion
one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction
end function
---
Please immediately let us know (by phone or return email) if (a) this

email

contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.698 / Virus Database: 455 - Release Date: 02/06/2004

[Jamie Collins]

"WindAndWaves" wrote ...

I noticed it is one
of those NEVER USE.

Only just noticed? <g> This is an old chestnut dating back to (at
least) 1968:

"For a number of years I have been familiar with the observation that
the quality of programmers is a decreasing function of the density of
go to statements in the programs they produce. More recently I
discovered why the use of the go to statement has such disastrous
effects, and I became convinced that the go to statement should be
abolished from all 'higher level' programming languages..."

Edager W. Dijkstra
Original Historic Documents, 351 commmunications of the ACM VoL11 (2),
1968 pp. 147-148

http://www.thocp.net/biographies/pap...ed_harmful.htm

--

[Steve Jorgensen]

On 8 Jun 2004 00:49:32 -0700, te********@hotmail.com (Edward) wrote:

....

>Sorry, but this is a mess.
>
>' Make scope explicit
>Public Sub Foo(colBar As VBA.Collection)
>
> ' This is the one place in all my code that I ever have a GoTo
> On Error GoTo FooErr
>
> If ((objBar Is Nothing) Or (objBar.Count = 0) Or (objBar(1) = "-")) Then
> ' Do your Clean Up And Exit stuff here
> Else
> ' Code body
> ' ...
> ' ...
> ' ...
> EndIf
>
> CleanUpAndExit:
> ' Clean-up code.
> ' ...
> FooErr:
> ' Error Handling
> Resume CleanUpAndExit
>End Sub
Paraphrasing Einstein - make the code as simple as possible, but no simpler.
Your code will not work, and in languages where it does work, it's not
self-documenting.

Of course it will work - it's air code.

Notice that each of the conditions will fail with an error if executed in the
wrong context.

Care to expand on that? I don't understand what you mean.

If you look at the code, it's pretty clear. If you try to inquire about the
colleciton count when there's no collection object, you get an error. Thus,
you can't check the count until -after- you make sure there's an object.
Next, you can't check the contents of the first entry in the collection until
you make sure there is at least one entry in the collection. If either there
is no colleciton, or it is empty, the code will fail when the conditions are
combined into a single If because VBA will try to evaluate all the conditions,
then perform the And operation on the results.

That's why the prior check must be done separately.

What prior check?

The prior check to make sure the current check will not cause an error -
checking for a collection before trying to actertain its count, ...

In some
languages, the language can short circuit logic and skip conditions that are
not necessary to check based on the previous condition in an And/Or expression
which would keep this code from failing. If you use short circuiting that
way, though, you are not expressing the dependencies, and someone (possibly
you) trying to read the code later is likely to change the order of operations
or insert a new condition in the wrong place, and break it.

What dependencies? I think you've lost the point of this whole
exercise, which was a discussion about the use of GoTo. It wasn't
about the entirely fictitious state of objbar. I don't give a pair of
pyjamas about the state of objbar.

My example is precisely about Goto - it's about a type of case where a
construction using Gotos can be more clear and easier to maintain than one
that isn't.

Finally, I don't agree that multiple conditions (more than 1 or 2) should be
run together in one statement/line because it's harder to visually parse them
out.

Not with my brain it isn't.

Yeah, everyone thinks they're superhuman. Why is it good to use lists of
bulleted items in a presentation? Because a human can read and comprehend it
more quickly than a big block of text. The same thing helps with code. If a
page contains many things that you have to take time to read to ascertain the
meaning, and there are too many on the page to hold them all in your brain at
oce, it's going to take you much longer to uravel that page when you come back
to it later. One thing you might do to help unravel it is improve legibility
by fixing what you should have fixed in the first place, and break up
logically distinct operations onto multiple lines using line continuations.
Would this paragraph have been quicker to read and comprehend if I'd turned it
into a set of bulleted items?

Even if they're in one If statement, put line continuations in, and get
the conditions onto separate lines.

Example:

If <condition1> Or _
<condition2> Or _
<condition3> _
Then
' Do stuff
End If

Horrible, ugly, unnecessary and error prone. I never use line
continuations except for strings. In any case, this is entirely a
matter of aesthetics, not language usage nor syntactical or logical
correctness.

You've explained why you think it's unnecessary, but now you need to explain
horrible, ugly, and error prone. I, on the other hand, think it's more
attractive, and less error prone. Since you can actually see all conditions
at once right next to each other, it's much easier to see if they all make
sense, there's no duplication, they follow the same form when they're supposed
to, etc.

Again, don't even do this in a guard clause case, though. A guard clause is
used when the next piece of code will fail under some condition, and in many
cases, such as my example, guard clauses must protect guard clauses -
sometimes several in a row.

Is there a typo in your example code? I only ask because the argument
to Foo is "colbar" but you reference "objbar" elsewhere?

Yes, that was a typo. My intention was to use colBar in all those places.

Edward

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:o9********************************@4ax.com:

On Mon, 7 Jun 2004 13:10:17 -0700, "R Baumann" <ry**@9yahoo.com>
wrote:

Goto should be a valuable part of your programming arsenal. Don't
let anyone ever tell you differently.

But it is so often misused, that it is sometimes more helpful to
teach people to avoid it altogether first, then tell them when
it's OK.

The original example that started this thread was a stupid example,
as it had a select case to branch to labels within a single
subroutine. There is no justification for such code structuring at
all. Either place the code directly in the appropriate CASE or use
the CASE to call an external subroutine. The latter would make the
most sense if the code is called from more than one context.

But one should be careful to evaluate whether one is implementing
with a lot of code duplication. You should look at the three
subroutines and see how much they have in common. If they are
basically doing the same thing with only a couple of exceptions,
then I'd say you'd be better off refactoring into a structure where
you did the common routines for all cases and did the exceptions
conditionally.

So, I really do think the original example served to derail the
discussion as it wasn't at all a realistic situation for GoTo, but a
ridiculously bad example of what is bad with GoTo thinking.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google.c om:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<0g********************************@4ax.com>. ..

On 7 Jun 2004 03:36:58 -0700, te********@hotmail.com (Edward)
wrote:

[...]

>> With guard clauses...
>> Sub Foo(colBar As VBA.Collection)
>> If objBar Is Nothing Then Goto Clean_Up_And_Exit
>> If objBar.Count = 0 Then Goto Clean_Up_And_Exit
>> If objBar(1) = "-" Then Goto Clean_Up_And_Exit
>> ' Code body
>> ' ...
>> ' ...
>> ' ...
>> Clean_Up_And_Exit:
>> ' Clean-up code.
>> ' ...
>> End Sub
>
>Sorry, but this is a mess.
>
>' Make scope explicit
>Public Sub Foo(colBar As VBA.Collection)
>
> ' This is the one place in all my code that I ever have a GoTo
> On Error GoTo FooErr
>
> If ((objBar Is Nothing) Or (objBar.Count = 0) Or (objBar(1) =
> "-")) Then
> ' Do your Clean Up And Exit stuff here
> Else
> ' Code body
> ' ...
> ' ...
> ' ...
> EndIf
>
> CleanUpAndExit:
> ' Clean-up code.
> ' ...
> FooErr:
> ' Error Handling
> Resume CleanUpAndExit
>End Sub

Paraphrasing Einstein - make the code as simple as possible, but
no simpler. Your code will not work, and in languages where it
does work, it's not self-documenting.

Of course it will work - it's air code.

No, you're absolutely wrong -- the code WILL NOT WORK if any one of
the first two conditions is TRUE -- it will throw a runtime error.

If the first if TRUE, you'll get a runtime error because the 2nd and
3rd will fail. If the 2nd is TRUE, the third will throw a runtime
error. The only cases in which the code will work properly is when
all three are FALSE or only the 3rd is TRUE.

Read the code.

Think what the code actually says.

You were treating Steve's example as if it had not important
content, and he chose his example very specifically to demonstrate
exactly where a GoTo is more appropriate and easier to maintain than
an If/Then/Else structure.

You are entirely missing the point by wrongly arguing that it could
be replaced by a single OR'd test.

And you got almost as nasty about as I do. I try to be in the right
when I get snarky -- doing otherwise not only makes you look like an
asshole, but it makes you like like an ignorant asshole as well.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"aaj" <a.*@c.com> wrote in
news:40**********************@news.easynet.co.uk:

This is probably a dumb question, but nothing ventured, nothing
gained, do for next loops use the stack? and if they do would
jumping out of a loop using goto prevent the stack from being
cleared i.e.

Private Sub test()
Dim i As Integer
Dim j as integer

For i = 1 To 1000
If some condition Then GoTo exit_here
Next i

jump_in_here:
For j= 1 To 1000
If some condition Then GoTo exit_here
Next i
You surely mean Next j there, right?
etc...

End

-------------------

exit_here:
' do things like print warnings and jump back in after the first
loop MsgBox i
MsgBox j
GoTo jump_in_here

End Sub

What I am wondering is if ending the loop doesn't clear the stack,
is it possible that using goto could eventually generate a stack
overflow?
You should use Exit For instead of GoTo.
I wouldn't do the above and I have no idea if For Next puts things
on the stack, its just out of interest really....

I don't get your question. What stack?

For i = 1 to 1000
Next i

is equivalent to:

i = 1
Do While i < 1001
i = i + 1
[code]
Loop

For/Each is much more useful with object variables like this:

Dim ctl As Control

For Each ctl in Me.Controls
[do something with ctl]
Next ctl

[of course, it's wise to set ctl = Nothing after doing this kind of
loop, just in case an implicit reference to the control doesn't get
cleared when the code ends]

Now, if you were jumping into a loop using the same counter, well,
that would seem pretty problematic. But I could actually see
something of a use for it -- once a certain condition is met, you
might want to loop through the rest of the items with a different
result.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[(Pete Cresswell)]

RE/

You made me laugh. But you never really told me what is wrong with it. Function x
select case z
case 1
goto one
case 2
goto two
case else
goto three
end select
exitFunction:
exit funtion one:
.....
goto exitFunction
two:
.................
goto exitFunction
three:
................
goto exitFunction

The basic idea is that code you wrote should be as easy as possible for somebody
else to understand. The guy reading a CASE statement is looking for the
processing for each case to happen either under that case or in a routine called
by that case. Your example isn't all that big sin...but somebody reading it
*does* have to do a sort of doubletake: "Huh...whaaaaa? Oh, I see he's
branching within the routine....". It's just innately more difficult to follow.
Not a great deal more difficult...but that stuff adds up quickly over the span
of an entire application.
--
PeteCresswell

[Trevor Best]

David W. Fenton wrote:

jump_in_here:
For j= 1 To 1000
If some condition Then GoTo exit_here
Next i

You surely mean Next j there, right?

The joys of copy and paste eh? :-)

You should use Exit For instead of GoTo.

Correct, I've yet to see a bit of code using gotos that cannot be
re-coded another way, if any code is designed properly, then gotos
aren't needed. Some languages don't have a goto command

I wouldn't do the above and I have no idea if For Next puts things
on the stack, its just out of interest really....

I don't get your question. What stack?

It's down at the machine code level and is just an area of reserved (by
the OS or by the program) FILO memory, when you use something like Call
or Gosub, the equivelent machine code will push the address of the
calling code onto the stack so that when you exit a function/sub or use
Return the value is popped off the stack and execution will continue at
the address after that point that was pushed.

In answer to aaj, no, a for/next loop doesn't use the stack, it's
iterative, stacks are used for recursion* The following code would blow
the stack...

Sub MySub()
Call MySub()
End Sub
*Recursion - Adj. See Recursion :-)

Stacks were often also used as a general purpose "I'll just put this to
one side and use it later" type store as it was very easy in assembler
to do this than to allocate a bit of ram, store a value, retrieve it
later then deallocate the ram (the last bit being something that some
people often forgot to do)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[WindAndWaves]

Hey Gurus

I could not keep up with all the posts. What a wealth of ideas. I will
read through it one more time, there are just so many ideas in it. Great.

Thank you all very much for your comments.
---
Please immediately let us know (by phone or return email) if (a) this email
contains a virus
(b) you are not the intended recipient
(c) you consider this email to be spam.
We have done our utmost to make sure that
none of the above are applicable. THANK YOU
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 06/06/2004

[Edward]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.90>...

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google.c om:
[...] You were treating Steve's example as if it had not important
content, and he chose his example very specifically to demonstrate
exactly where a GoTo is more appropriate and easier to maintain than
an If/Then/Else structure.
Taking Steve's example as he intended it (i.e. colBar = objBar), then
I agree that I couldn't OR the three conditions. Mea culpa. However,
if he had been so particular with his example, presumably putting it
into a code module and compiling it would have alerted him to the
undeclared variable objBar

However, there's still no excuse or need for a Goto.

Sub Foo(colBar As VBA.Collection)
If colBar Is Nothing Then
' Deal with it
ElseIf colBar.Count = 0 Then
' Deal with it
ElseIf colBar(1) = "-" Then
' Deal with it
Else
' At last. Let's get on with it.
EndIf

This code is just as easy to read and maintain as Steve's.
And you got almost as nasty about as I do. I try to be in the right
when I get snarky -- doing otherwise not only makes you look like an
asshole, but it makes you like like an ignorant asshole as well.

So by inference you normally look like an asshole (when you are snarky
which is quite a lot of the time), except for those times when you are
wrong (presumably sometimes) when you too look like an ignorant
asshole. Fair enough - at least you're honest. Me? Your opinion of
me matters rather little, I find.

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

[Steve Jorgensen]

On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward) wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.90>...

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google.c om:

[...]

You were treating Steve's example as if it had not important
content, and he chose his example very specifically to demonstrate
exactly where a GoTo is more appropriate and easier to maintain than
an If/Then/Else structure.

Taking Steve's example as he intended it (i.e. colBar = objBar), then
I agree that I couldn't OR the three conditions. Mea culpa. However,
if he had been so particular with his example, presumably putting it
into a code module and compiling it would have alerted him to the
undeclared variable objBar

However, there's still no excuse or need for a Goto.

Sub Foo(colBar As VBA.Collection)
If colBar Is Nothing Then
' Deal with it
ElseIf colBar.Count = 0 Then
' Deal with it
ElseIf colBar(1) = "-" Then
' Deal with it
Else
' At last. Let's get on with it.
EndIf

This code is just as easy to read and maintain as Steve's.

It's not bad - certainly acceptable, but the there are reasons to prefer the
guard clause construction. First, the main body is the main body - the main
purpose of the procedure. Putting it in an Else makes it look more like an
exceptional case, not the focus of attention. Second, shorter is oftern
better. Your code needs comments to clarify why the If and ElseIf conditions
are empty. We should add comments where something needs clarification, but
if we can make the code describe itself enough that comments are unnecessary,
that's usually better.

[Edward]

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<n9********************************@4ax.com>. ..

On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward) wrote:
[...] It's not bad - certainly acceptable, but the there are reasons to prefer the
guard clause construction. First, the main body is the main body - the main
purpose of the procedure. Putting it in an Else makes it look more like an
exceptional case, not the focus of attention. Second, shorter is oftern
better. Your code needs comments to clarify why the If and ElseIf conditions
are empty. We should add comments where something needs clarification, but
if we can make the code describe itself enough that comments are unnecessary,
that's usually better.

My "If" and "ElseIf" aren't empty - I just didn't put the code in
there that would deal with the exceptions! I'm lazy, m'kay? Also, my
comments were crap.

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

[Steve Jorgensen]

On 10 Jun 2004 00:12:13 -0700, te********@hotmail.com (Edward) wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<n9********************************@4ax.com>. ..

On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward) wrote:

[...]

It's not bad - certainly acceptable, but the there are reasons to prefer the
guard clause construction. First, the main body is the main body - the main
purpose of the procedure. Putting it in an Else makes it look more like an
exceptional case, not the focus of attention. Second, shorter is oftern
better. Your code needs comments to clarify why the If and ElseIf conditions
are empty. We should add comments where something needs clarification, but
if we can make the code describe itself enough that comments are unnecessary,
that's usually better.

My "If" and "ElseIf" aren't empty - I just didn't put the code in
there that would deal with the exceptions! I'm lazy, m'kay? Also, my
comments were crap.

OK, cut the defensive crap. What I think we should be doing here is
discussing the pros and cons of different styles. If you'd rather be snotty,
this is my last reply because talking to someone who doesn't want to listen is
rather a waste of time.

Actually, I don't think your comments were crap, I think they or something
like them was pretty much good style for that code construction. If you leave
the blocks empty with no comments, then it looks like you just didn't finish
the code, so the comments -are needed, and that brings me to what I'm getting
at.

Sometimes, code simply requires comments to be clear, but I prefer, when
possible, to change the code so the comments aren't needed to make the
intention transparent. I think the guard clause construction does that nicely
for many cases including the one we are currently referencing, and so do the
respected people I learned it from in the books I read to learn about it.

Eventually, coding style does come down to personal preference, and you and I
might simply have different preferences. I think, however, that guard clauses
are very good things that can simplify and clarify code.

[aaj]

Ah...well remembered, the thought came from back in 1986 ish when I moved
from assembler to Basic. I'd forgotten the exact details and assumed it was
the loop that pushed, popped things on and off the stack.

My memory is fading but I now sort of remember (as you correctly point
out) being taught that using goto to leave a gosubed or called routine and
then jump back to a position in a calling loop using GoTo could fill up the
stack as the gosub data would never be cleared off.

Do these new fangled visual languages 8-) still work in the same way, if
they do then I suppose that as far as the original question goes then its
another reason not to use them to jump out of subroutines back into the main
body

again well remembered

thanks

Andy
P.s. for what its worth, and I know nothing compared to most people in the
group, but the last time I used goto other than error handling was when each
line had a unique number 10,20,30,..... ah those were the days 8-)
"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

David W. Fenton wrote:

jump_in_here:
For j= 1 To 1000
If some condition Then GoTo exit_here
Next i

You surely mean Next j there, right?

The joys of copy and paste eh? :-)

You should use Exit For instead of GoTo.

Correct, I've yet to see a bit of code using gotos that cannot be
re-coded another way, if any code is designed properly, then gotos
aren't needed. Some languages don't have a goto command

I wouldn't do the above and I have no idea if For Next puts things
on the stack, its just out of interest really....

I don't get your question. What stack?

It's down at the machine code level and is just an area of reserved (by
the OS or by the program) FILO memory, when you use something like Call
or Gosub, the equivelent machine code will push the address of the
calling code onto the stack so that when you exit a function/sub or use
Return the value is popped off the stack and execution will continue at
the address after that point that was pushed.

In answer to aaj, no, a for/next loop doesn't use the stack, it's
iterative, stacks are used for recursion* The following code would blow
the stack...

Sub MySub()
Call MySub()
End Sub
*Recursion - Adj. See Recursion :-)

Stacks were often also used as a general purpose "I'll just put this to
one side and use it later" type store as it was very easy in assembler
to do this than to allocate a bit of ram, store a value, retrieve it
later then deallocate the ram (the last bit being something that some
people often forgot to do)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google.c om:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<n9********************************@4ax.com>. ..

On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward)
wrote:

[...]

It's not bad - certainly acceptable, but the there are reasons to
prefer the guard clause construction. First, the main body is
the main body - the main purpose of the procedure. Putting it in
an Else makes it look more like an exceptional case, not the
focus of attention. Second, shorter is oftern better. Your code
needs comments to clarify why the If and ElseIf conditions are
empty. We should add comments where something needs
clarification, but if we can make the code describe itself enough
that comments are unnecessary, that's usually better.

My "If" and "ElseIf" aren't empty - I just didn't put the code in
there that would deal with the exceptions! I'm lazy, m'kay?
Also, my comments were crap.

Apparently, you still haven't comprehended Steve's code.

THERE IS NOTHING TO DO BUT EXIT when the conditions in the IF and
ELSEIF clauses are true.

THERE IS NO CODE MISSING except for EXIT SUB.

In terms of readability, though, this wouldn't bother me:

If colBar Is Nothing Then Exit Sub
ElseIf colBar.Count = 0 Then Exit Sub
ElseIf colBar(1) = "-" Then Exit Sub
Else
[do what the sub is for]
EndIf

However, I still prefer Steve's method, as it shows that the three
tests are independent of each other (though they must be performed
in a certain order) and that once they are done, there are no more
dependencies. You're just checking initial conditions to see whether
it's safe to do the sub's main task.

The If/ElseIf approach doesn't really make that clear to me, though
that's certainly a matter of personal preference.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Thu, 10 Jun 2004 14:12:35 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google. com:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<n9********************************@4ax.com>. ..

On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward)
wrote:

[...]

It's not bad - certainly acceptable, but the there are reasons to
prefer the guard clause construction. First, the main body is
the main body - the main purpose of the procedure. Putting it in
an Else makes it look more like an exceptional case, not the
focus of attention. Second, shorter is oftern better. Your code
needs comments to clarify why the If and ElseIf conditions are
empty. We should add comments where something needs
clarification, but if we can make the code describe itself enough
that comments are unnecessary, that's usually better.

My "If" and "ElseIf" aren't empty - I just didn't put the code in
there that would deal with the exceptions! I'm lazy, m'kay?
Also, my comments were crap.

Apparently, you still haven't comprehended Steve's code.

THERE IS NOTHING TO DO BUT EXIT when the conditions in the IF and
ELSEIF clauses are true.

THERE IS NO CODE MISSING except for EXIT SUB.

In terms of readability, though, this wouldn't bother me:

If colBar Is Nothing Then Exit Sub
ElseIf colBar.Count = 0 Then Exit Sub
ElseIf colBar(1) = "-" Then Exit Sub
Else
[do what the sub is for]
EndIf

Actually, that's not a bad stye excetp that it's not valid code <g>. If you
put the statement on the same line after the If, you can't follow it with
ElseIf or Else. You get an ElesIF without If error.

[Edward]

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<br********************************@4ax.com>. ..

On 10 Jun 2004 00:12:13 -0700, te********@hotmail.com (Edward) wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in message

OK, cut the defensive crap. What I think we should be doing here is
discussing the pros and cons of different styles. If you'd rather be snotty,
this is my last reply because talking to someone who doesn't want to listen is
rather a waste of time.

Snotty? I think you need to get out more! And clearly my comments
were crap, since they didn't do what they were supposed to do. For
example, I SHOULD have written

' Put in code here to deal with objBar = Nothing

Please don't get snippy - you're one of the good guys. I probably
shouldn't have come across all gung-ho, especially as I hardly do any
Access work any more (more's the pity - ASP.NET is a nightmare by
comparison)

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk

"We may see the small value God has for riches, by the people he gives
them to".
Edward

[Steve Jorgensen]

On 10 Jun 2004 07:43:08 -0700, te********@hotmail.com (Edward) wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<br********************************@4ax.com>. ..

On 10 Jun 2004 00:12:13 -0700, te********@hotmail.com (Edward) wrote:

>Steve Jorgensen <no****@nospam.nospam> wrote in message OK, cut the defensive crap. What I think we should be doing here is
discussing the pros and cons of different styles. If you'd rather be snotty,
this is my last reply because talking to someone who doesn't want to listen is
rather a waste of time.

Snotty? I think you need to get out more! And clearly my comments
were crap, since they didn't do what they were supposed to do. For
example, I SHOULD have written

If you weren't trying to be snotty - great. That is how you came off,
however. Expressing proper intention in text alone takes some finesse, and I
don't always succeed myself. Just for the record, my intended emotion in my
reply above was - snippy <g>.
' Put in code here to deal with objBar = Nothing
But in the case we are talking about, the procedure needs to do nothing at all
in any of the guard clause cases, except perhaps, mandatory clean-up. Since
the clean-up code is the same in all cases, however, copying it into each
If/ElseIf/ block would be duplication.
Please don't get snippy - you're one of the good guys. I probably
shouldn't have come across all gung-ho, especially as I hardly do any
Access work any more (more's the pity - ASP.NET is a nightmare by
comparison)

Thanks for the compliment. Since I have valid elder status here now, I was
experimenting with showing a little attitute. I'll make note that some people
appreciate my non-confrontational mode.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:pb********************************@4ax.com:

On Thu, 10 Jun 2004 14:12:35 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google .com:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<n9********************************@4ax.com>. ..
On 9 Jun 2004 06:44:45 -0700, te********@hotmail.com (Edward)
wrote:

[...]
It's not bad - certainly acceptable, but the there are reasons
to prefer the guard clause construction. First, the main body
is the main body - the main purpose of the procedure. Putting
it in an Else makes it look more like an exceptional case, not
the focus of attention. Second, shorter is oftern better.
Your code needs comments to clarify why the If and ElseIf
conditions are empty. We should add comments where something
needs clarification, but if we can make the code describe
itself enough that comments are unnecessary, that's usually
better.

My "If" and "ElseIf" aren't empty - I just didn't put the code
in there that would deal with the exceptions! I'm lazy, m'kay?
Also, my comments were crap.

Apparently, you still haven't comprehended Steve's code.

THERE IS NOTHING TO DO BUT EXIT when the conditions in the IF and
ELSEIF clauses are true.

THERE IS NO CODE MISSING except for EXIT SUB.

In terms of readability, though, this wouldn't bother me:

If colBar Is Nothing Then Exit Sub
ElseIf colBar.Count = 0 Then Exit Sub
ElseIf colBar(1) = "-" Then Exit Sub
Else
[do what the sub is for]
EndIf

Actually, that's not a bad stye excetp that it's not valid code
<g>. If you put the statement on the same line after the If, you
can't follow it with ElseIf or Else. You get an ElesIF without If
error.

You're right, of course!

Done properly, it's the same as your GoTo.

Empty If/ElseIf conditions always look to me like bad code design.

Your "guard clauses" don't cause me to wonder what's wrong with the
code structure.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

te********@hotmail.com (Edward) wrote in
news:25**************************@posting.google.c om:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<br********************************@4ax.com>. ..

On 10 Jun 2004 00:12:13 -0700, te********@hotmail.com (Edward)
wrote:

>Steve Jorgensen <no****@nospam.nospam> wrote in message OK, cut the defensive crap. What I think we should be doing here
is discussing the pros and cons of different styles. If you'd
rather be snotty, this is my last reply because talking to
someone who doesn't want to listen is rather a waste of time.

Snotty? I think you need to get out more! And clearly my
comments were crap, since they didn't do what they were supposed
to do. For example, I SHOULD have written

' Put in code here to deal with objBar = Nothing

But the point is THERE'S NOTHING NEEDED BUT TO EXIT.
Please don't get snippy - you're one of the good guys. I probably
shouldn't have come across all gung-ho, especially as I hardly do
any Access work any more (more's the pity - ASP.NET is a nightmare
by comparison)

You were quite firm about how wrong Steve was when, in fact *you*
were wrong.

Of course, I've now discredited myself by posting invalid code.

So I won't get to vehement in my condemnations.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:i1********************************@4ax.com:

Since I have valid elder status here now, I was
experimenting with showing a little attitute. I'll make note that
some people appreciate my non-confrontational mode.

I think your reaction was perfectly appropriate.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

I am in the "Judicious Use" camp. Unfortunately, my "Judicious Use" criteria
of "so rare that it's almost never" is not universally shared. <SIGH>

(Still wondering whatever happened to "That Thar Jaysmith", and a few others
from the "olden days".)

Larry
"Trevor Best" <nospam@localhost> wrote in message
news:40**********************@auth.uk.news.easynet .net...

Larry Linson wrote:

"Trevor Best" wrote

> Gotos just mess up the flow of
> the code. Spaghetti code is not
> easy to follow, well structured
> code is.

Trevor, it is possible to write spaghetti code that has not a single
violation of structure. I have seen examples. It was the _logic_ of those 60,000 lines of PL/1 that was incomprehensible.

IKWYM, DataEase's DQL didn't have gotos (or even gosubs) and I've seen
(and fixed) some horrendous code in that.

It still doesn't make a gotos look any better :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:rh*****************@nwrddc02.gnilink.net:

I am in the "Judicious Use" camp. Unfortunately, my "Judicious
Use" criteria of "so rare that it's almost never" is not
universally shared. <SIGH>

Well, I don't use GoTo rarely, because I have lots of error handlers
in my code.

But for everything *other* than error handlers (or jumping to an
exit routine for cleanup, as with Steve's "guard clauses"), my use
of GoTo is very rare.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Thu, 10 Jun 2004 16:36:21 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:i1********************************@4ax.com :

Since I have valid elder status here now, I was
experimenting with showing a little attitute. I'll make note that
some people appreciate my non-confrontational mode.

I think your reaction was perfectly appropriate.

Of course it was, but I'll always listen to opinions within reason regarding
how I communicate. After all, I don't have to be gruff, we've got others here
who can do that <g>.

[Trevor Best]

David W. Fenton wrote:

"Larry Linson" <bo*****@localhost.not> wrote in
news:rh*****************@nwrddc02.gnilink.net:

I am in the "Judicious Use" camp. Unfortunately, my "Judicious
Use" criteria of "so rare that it's almost never" is not
universally shared. <SIGH>

Well, I don't use GoTo rarely, because I have lots of error handlers
in my code.

But for everything *other* than error handlers (or jumping to an
exit routine for cleanup, as with Steve's "guard clauses"), my use
of GoTo is very rare.

ISTR this discussion b4, about jumping to an exit routine. It's nice to
have just one exit point in a sub so you only need any cleanup code once
but as I've said b4, you can still avoid gotos, e.g.

<---
blah
do until <condition1>
if <condition2> then
' no futher processing needed
Goto ExitHere
end if
loop
blah
blah
ExitHere:
blah
Exit Sub
ErrTrap:
blah
--->

Can be re-coded as...

<---
Dim fExit As Boolean
blah
do until <condition1>
if <condition2> then
' no futher processing needed
fExit = True
end if
loop
if not fExit then
blah
blah
end if
ExitHere:
blah
Exit Sub
ErrTrap:
blah
--->

But of course you may need lots of conditions then the above can look a
bit wild, I usually cheat when I want to cleanup exit immediately I use:

Err.Raise 1,,"Quiet exit"

Then trap Error 1

--
Error reading sig - A)bort R)etry I)nfluence with large hammer