Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Why are GOTO statements bad ?

Status
Not open for further replies.
Mar 29, 2010
20
0
0
GB
Why are GOTO statements bad?

I've been writing SQL without any GOTO statements but recently became aware that they can be used in SQL Server 2005, but when I try to research it, people just flame the use of it.

Everyone says it's bad practice, and there are almost always more elegant solutions, blah blah blah, but if it works then why not use it? We are writing SQL statements not composing classical music, whats the problem?
 
In my opinion...

Goto statements should be avoided because they can make code more difficult to read and understand. Goto is a VERY simple concept to understand. As such, programmers (and people in general) have a tendency to over use well understood concepts.

Most of the time, GOTO is not needed. In fact, I don't have a single goto in any of my SQL code (and there is a lot of code). Since it it not needed, and can be abused, it's best to avoid it's use altogether.

Many programmers have the same attitude towards entire programming languages. Take VB6 for example... When many programmers hear about VB6, they snigger and some begin laughing uncontrollably. Why? Because it is easy to write extremely awful code with it. It does not matter that you CAN write very powerful applications that are elegantly written and relatively easy to maintain. It's got that bad reputation because the language was abused by a lot of people.

The GOTO statement has that same bad reputation.

-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom
 
RiddleMeThis said:
it works then why not use it?
Because badly structured code will soon break down, and then when you need to fix it you will not be able to grasp what it is supposed to do. I'm not talking about Goto statements specifically, but rather the difference between well structured code vs. "just make it work as quickly as possible".

Good programmers don't make "elegant" code just for aesthetics or because they enjoy the mental excercise, but because it's cost effective. The well written code will always result in far less down time and costly mistakes than the "fiddle with it until it seems to work" (use of Goto statements often indicates an amateur who works by "trial and error").

You probably get flamed when you bring up Goto because many of us have inherited monstrosities written by bad programmers. It's no fun cleaning up somebody else's mess.
 
I agree with the reasons stated…I started programming in COBOL when GoTO was used quite a bit in what was called “spagetti code” and structured coding was just becoming the standard. “Spagetti code” is basically straight line, fall through coding and not only was the flow controled by GoTo but also GoTo depending on (the contents of a variable). It could be very difficult to debug. Especially back then when the debugging environment was looking at print outs of the code and traces and displays. There was no interactive debugging tools available like today. A big change in the structured methodology was if code is strucured properly then not a single GoTo was needed. I think during that transition GoTo became an evil word and the tool of the lazy.

That said I use them here and there where it is obvious what is happening in a single glance. Maybe just to p*ss off the purists J
 
GOTO has its place if SPEED is of major importance. Regardless of how well structured you code in order to avoid GOTO you do need to add lots of conditions and branching. This may make the code cleaner, but it has its effect on speed. But this is not something you would normally consider outside of low level OS kernel development.
Definitely I would not consider using it on SQL

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top