I've recently had a lot of fun helping Graham, an About Visual Basic reader from the UK, work out some bugs in a program he's writing. Graham's bugs have been some of the most interesting I have seen in a while. (One very interesting bug about disappearing Label Text is included just because it's interesting as a link at the end of the article.)
One bug has turned out to be such a great example showing why the use of GoTo remains a really, really bad idea that I had to write this article about it. In fact, I thought GoTo wasn't allowed in VB.NET anymore except in unstructured error handling. I haven't seen one since I was a Cobol programmer years ago.
GoTo is such a bad idea many people feel that the movement to eliminate it is actually the start of Object Oriented Programming (OOP). A historic article in 1968, "Go To Statement Considered Harmful" by Edsger W. Dijkstra, was an important part of starting the OOP movement. For years, instead of "Object Oriented Programming" or "Structured Programming", the style was known as "GoTo-less Programming".
But why is it such a bad idea? Cobol and Fortran programmers (and I was one of them) used "Go To" constantly for many years in complex banking and engineering systems that ran the world's business. Back in 1975, it was very hard to tell a senior programmer in a Cobol shop who had written hundreds of successful programs with thousands of Go To statements that it was a bad idea.
Reading Dijkstra's original paper is a good place to start. In that paper, he points out that the description of the source code of a program as "successive action descriptions" can mean two different things:
- (successive action) descriptions -- actions that are successive in time when the program runs
- successive (action descriptions) -- actions that are successive in the program source code
Think about it ... these are only the same if Go To isn't allowed.
When a Go To is used in a program, the entire state of the program - all of the values of all of the variables, the state of whatever sequence of calls has occurred, the state of files that may be in the process of being read or updated - is transplanted to another arbitrary part of the program where just one of those things might have some disasterous effect. As Dijkstra put it, "use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress."
The golden quality of objects is that they are guaranteed to be self contained ("encapsulation" is the OOP word) so you can concentrate on understanding what's happening in just one thing at a time: the code of the software object that you're working on.
But all this may still not make much sense to you, so without further verbage, lets consider Graham's actual program.
Randomize()
For Number = 0 To 8
Start:
intNumber = Int((N * Rnd()) + 1)
For y = 0 To 8
' If number already selected
' then select another one
If intNumber = arrNumber(y) Then GoTo Start
Next y
arrNumber(Number) = intNumber
Next Number
