Are gotos truly evil?

[Guest]

I have never used a goto statement in my code, one of the first things I was
told in my software classes a number of years ago was "goto statements are
evil and lead to spagetti code - do not use them".

I absorbed this mantra and tell this to other people and I fully believe in
it. However, I was talking to someone recently and he was saying how much he
loved goto statements and how useful they were and that Microsoft had to
leave them in c# because they were so useful, otherwise why would the
statement be in the language. He does not advocate using them in excess but
uses them to allow himself to create a pattern that allows him to have one
point of exit in a function at the end. I kept trying to convince him that
gotos were not good but he seemed unconvinced by my arguements.

I know one common use people say is for getting out of deeply nested
statements but you can easily do without gotos by using booleans or replacing
sections of code with function calls.

Why if they are so bad is goto still in the language, what are the
acceptable uses of the keyword, there must be some otherwise why is the
statement in the c# language, or is this just a legacy thing to attract
programmers from other languages who are used to gotos?

I can't think of any really valid reason why you would use them but maybe
other people have.

 

[Steve Walker]

I have never used a goto statement in my code, one of the first things I was
told in my software classes a number of years ago was "goto statements are
evil and lead to spagetti code - do not use them".

I absorbed this mantra and tell this to other people and I fully believe in
it. However, I was talking to someone recently and he was saying how much he
loved goto statements and how useful they were and that Microsoft had to
leave them in c# because they were so useful, otherwise why would the
statement be in the language.

"Rules are for the obedience of fools and the guidance of wise men."
(Douglas Bader)

I can't think of any really valid reason why you would use them but maybe
other people have.

Nor I. If I came across a situation where using goto made sense, I'd
treat it with suspicion, on the grounds that the structure of the code
was probably fundamentally flawed. If, on examination, there wasn't a
better way of writing it, I'd go ahead and use it.

I think the OO mindset of treating long methods with complex flow
control as a code smell probably contributes to a style of programming
in which the issue does not occur.

 

[Nick Malik [Microsoft]]

I have never used a goto statement in my code, one of the first things I
was
told in my software classes a number of years ago was "goto statements are
evil and lead to spagetti code - do not use them".

I absorbed this mantra and tell this to other people and I fully believe
in
it. However, I was talking to someone recently and he was saying how much
he
loved goto statements and how useful they were and that Microsoft had to
leave them in c# because they were so useful, otherwise why would the
statement be in the language. He does not advocate using them in excess
but
uses them to allow himself to create a pattern that allows him to have one
point of exit in a function at the end. I kept trying to convince him
that
gotos were not good but he seemed unconvinced by my arguements.

I know one common use people say is for getting out of deeply nested
statements but you can easily do without gotos by using booleans or
replacing
sections of code with function calls.

Why if they are so bad is goto still in the language, what are the
acceptable uses of the keyword, there must be some otherwise why is the
statement in the c# language, or is this just a legacy thing to attract
programmers from other languages who are used to gotos?

I can't think of any really valid reason why you would use them but maybe
other people have.

Statements in languages are not evil. However, a statement that so trivial
to misuse is pointless to use. Using a goto just isn't worth it. All of
the developers I know that use 'goto' (and there are only a handful) are
pre-structured programmers first and foremost. They have no desire to learn
to use any of the techniques of OO programming or even good structured
programming. I cannot speak for your co-worker, but from what you describe,
the arguments are similar.

Don't waste your time arguing with these folks. If you have any say in the
matter, don't let them design anything of importance either. They want to
sit in the backwaters of software development... let them. You are not
their keeper. If you get their code, refactor it. Don't go our of your
way, but don't leave junk in the code base if you can safely remove it. In
other words, don't let yourself be held back by the slackers and luddites.
It's not good for the ol' career.

I cannot speak for the designers of C#. I was not involved in any way. In
my opinion, the goto was included to make it easy to port existing code, not
to help bring over the programmers who wrote that code. Those people are
happy to stay behind and I, for one, and happy to let them.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Michael A. Covington]

I have never used a goto statement in my code, one of the first things I
was
told in my software classes a number of years ago was "goto statements are
evil and lead to spagetti code - do not use them".

If they had no legitimate uses, programming languages would not include
them.

I find them useful in coding algorithms that are essentially big
state-transition networks. Each block of code represents one state, and
upon a state change, you jump to another block of code.

This is not a common kind of algorithm, of course, but it's a legitimate
one. Naturally, you have to be careful how you code it.

"Gotos are no substitute for if-then-else blocks, for loops, etc." - I
agree.

"Gotos have no legitmate uses" - Falsch.

We don't want to teach knee-jerk programming, where programmers
automatically do one thing because they've been told to, not because they've
considered the alternatives.


Michael Covington
Associate Director, Artificial Intelligence Center
The University of Georgia - www.ai.uga.edu/mc

 

[Michael A. Covington]

Statements in languages are not evil. However, a statement that so
trivial to misuse is pointless to use. Using a goto just isn't worth it.
All of the developers I know that use 'goto' (and there are only a
handful) are pre-structured programmers first and foremost. They have no
desire to learn to use any of the techniques of OO programming or even
good structured programming. I cannot speak for your co-worker, but from
what you describe, the arguments are similar.

Don't waste your time arguing with these folks. If you have any say in
the matter, don't let them design anything of importance either. They
want to sit in the backwaters of software development... let them. You
are not their keeper. If you get their code, refactor it. Don't go our
of your way, but don't leave junk in the code base if you can safely
remove it. In other words, don't let yourself be held back by the
slackers and luddites. It's not good for the ol' career.

Pardon me, but that's a bit frightening to read. Do you actually work for
Microsoft?

If one of my students wrote what you've just written, I'd call him in and
say, "Master the 'goto' statement yourself before you tell other people that
they are stupid for using it. An interesting class of algorithms seems to
be beyond your present knowledge of computer programming."

Knuth uses 'goto' in The Art of Computer Programming.

I don't use them often, but there are one or two 'goto' statements in my
latest and biggest (20,000-line?) object-oriented C# program. There really
are places where 'goto' is better than the alternatives. They're uncommon,
but I see no advantage in being unable to recognize them.

Have you ever programmed in assembly language? There, 'goto' is obligatory,
and you quickly learn how to use it systematically and reliably. Mostly,
you write things that are equivalent to loops or blocks in higher-level
languages, but occasionally, you see that a 'goto' can do something useful
that has no direct equivalent in structured programming.

Slacker? Luddite? Me???

Michael Covington, Ph.D.
Associate Director, Artificial Intelligence Center
The University of Georgia - www.ai.uga.edu/mc

 

[Bill Butler]

I find them useful in coding algorithms that are essentially big state-transition networks. Each
block of code represents one state, and upon a state change, you jump to another block of code.

I agree,
I have seen truly elegant state machines using goto.
It could have been written with a ton of function calls instead, but at a reduction in performance.
It could have been written with the "goto" stuff inlined, but that would have produced a monolithic
mess.
The "goto" version was highly structured and highly efficient.

This state machine was also written by a knowledgeable programmer who understood the pitfalls.

I have also seen goto abused in the worst possible way.
I did a stint at COBOL programming a few years ago and spaghetti is a nice word for some of that
code.
After failing to wrap my brain around some truly spectacularly illogical Moebius code I had to
restrain myself from seeking out the programmer responsible and removing his taint from the gene
pool.

As a rule of thumb.
GOTOs should only be used by SKILLED programmers who understand the consequences.
Novice programmers should avoid GOTOs at all costs.

That said, I have not needed a single goto in my last few years of C# programming.

My 2 cents
Bill Butler

 

[rossum]

I have never used a goto statement in my code, one of the first things I was
told in my software classes a number of years ago was "goto statements are
evil and lead to spagetti code - do not use them".

I absorbed this mantra and tell this to other people and I fully believe in
it. However, I was talking to someone recently and he was saying how much he
loved goto statements and how useful they were and that Microsoft had to
leave them in c# because they were so useful, otherwise why would the
statement be in the language. He does not advocate using them in excess but
uses them to allow himself to create a pattern that allows him to have one
point of exit in a function at the end. I kept trying to convince him that
gotos were not good but he seemed unconvinced by my arguements.

I know one common use people say is for getting out of deeply nested
statements but you can easily do without gotos by using booleans or replacing
sections of code with function calls.

Why if they are so bad is goto still in the language, what are the
acceptable uses of the keyword, there must be some otherwise why is the
statement in the c# language, or is this just a legacy thing to attract
programmers from other languages who are used to gotos?

I can't think of any really valid reason why you would use them but maybe
other people have.

THere are a few places where goto can be useful. I had to code one
after about five years of programming, and I got a compile error - "go
to" vs "goto"!

Certainly for a novice the rule of thumb is to avoid them generally in
structured languages.

The classic source for this is "Go To Statement Considered Harmful" by
Edsger W. Dijkstra. See http://www.acm.org/classics/oct95/

rossum



The ultimate truth is that there is no ultimate truth

 

[Nick Malik [Microsoft]]

Pardon me, but that's a bit frightening to read. Do you actually work for
Microsoft?

I do not speak for my employer and I'm sure that if there was a single
person who represents Microsoft, that person would likely distance
themselves from me quite readily. I am required by the policy of
Microsoft to declare myself to be an employee in all communications. We are
an opinionated bunch. For every opinion I express here, I can quite easily
find someone inside Microsoft that is happy to disagree with me.

If one of my students wrote what you've just written, I'd call him in and
say, "Master the 'goto' statement yourself before you tell other people
that they are stupid for using it.

Minor correction: I did not call anyone stupid. I did call the folks who
use goto "slackers" and "luddites". That does not make them stupid. Some
of the smartest people I know fail to be motivated to learn good OO
techniques, and adherance to an idea, including the idea that "newer is not
necessarily better," does not imply either ignorance or stupidity. That
said, I will say that no code review that I have sat through wouldn't end in
a shouting match if a 'goto' was left in the code. We have code analysis
tools that will flag the use of the word and will make sure that it shows up
in the review process.

An interesting class of algorithms seems to be beyond your present
knowledge of computer programming."

I maintain that there are no algorithms that REQUIRE this simple structure
(I may be wrong on this point). I gladly concede that there are algorithms
that can be made more efficient with the use of this construct. I have
never actually coded any of them, nor have any of the other folks that I
have worked with. I have written code to run embedded in data
communications devices, code inside the operating system, code in literally
dozens of applications, code in B2B transaction systems, code in B2C
e-commerce web sites, and code in application engines ranging from workflow
to EAI. I have never happened across a single algorithm that REQUIRED the
use of a goto.

Knuth uses 'goto' in The Art of Computer Programming.

According to the following site
(http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming), Volume 1 was
published in 1968. Volume 2 in 1969 and Volume 3 in 1972. I would be
surprised if you consider these volumes to represent the complete learnings
of computer science, for to make that statement, you would state that
innovation stopped over 30 years ago.

I have a great deal of respect for Dr. Knuth. He did a great job of
describing algorithms in a simple and clear manner for two generations of
software developers to learn from. However, the needs of simplicity for
teaching an algorithm is not the same as the needs of an organization for
maintaining reliable and trustworthy code.

I don't use them often, but there are one or two 'goto' statements in my
latest and biggest (20,000-line?) object-oriented C# program. There
really are places where 'goto' is better than the alternatives.

That depends on what you mean by 'better.'

I am involved in the creation of systems where the total investment in code
will usually exceed 30 million dollars. These systems will be maintained by
people who did not write the code, often many people, with one team
replacing another. In some cases, these team turnovers can occur four or
five times while the code is still considered important enough not to sunset
it.

In this environment, the cost of a single line of code is 10 times what it
cost to write and debug it. In this environment, anything that could add
complexity or confusion MUST be factored out as soon as possible. I don't
know what kind of environment you write code in, sir, but if you were to
give me a program with a 'goto' in it, I would ask you kindly to remove it.
If you chose to disagree, I'd stop your app from going into production until
you did.

They're uncommon, but I see no advantage in being unable to recognize
them.

'Advantage' is another term like 'better' above. It has a meaning that is
relative to its context.

Have you ever programmed in assembly language?

Two processor families. Total of three years. I wrote kernel code and
telecom firmware.

There, 'goto' is obligatory, and you quickly learn how to use it
systematically and reliably.

Agreed. Thank heaven for the C programming language. The amount of
assembly that I've had to actually live with is thankfully small.

Mostly, you write things that are equivalent to loops or blocks in
higher-level languages, but occasionally, you see that a 'goto' can do
something useful that has no direct equivalent in structured programming.

Once again, that depends on your definition of 'useful'.

Slacker? Luddite? Me???

Michael Covington, Ph.D.
Associate Director, Artificial Intelligence Center
The University of Georgia - www.ai.uga.edu/mc

I am flattered that a person of such learning would respond to my message.
I salute you for your accomplishments. Understand, however, that I do not
agree with you on this point, but not because I think you to be 'stupid.'
Far from it. It is because, in my world (and in the world of most software
developers), whether in product development or in Information Technology,
the _cost_ of a 'goto' far exceeds its _value_.

Understand that I am not interested in discussing a particular algorithm and
why 'goto' is better in that case. I'm sure that you can make a passionate
and lucid case for it. I maintain that there is no algorithm that requires
the 'goto' but I leave open the possibility that I am not correct. To be
honest, it doesn't matter. There are algorithms, I'm sure, in someone's
code, that makes use of it, and potentially to a positive effect if you view
the code only from the standpoint of performance.

I do not.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Nick Malik [Microsoft]]

If they had no legitimate uses, programming languages would not include
them.

Many things are included in programming languages for purposes that do NOT
apply to new code development. While I cannot and will not speak for C#, I
can say that considerations such as backwards compatibility with similar
languages is a factor in language development. If by including a statement,
the language can be used more easily to port 1,000,000 lines of C or even
Cobol code, then the statement is valuable, even if no one is using it for
new coding.

I find them useful in coding algorithms that are essentially big
state-transition networks. Each block of code represents one state, and
upon a state change, you jump to another block of code.

I have coded a few systems that use state transition mechanisms, from data
communication to workflow, and none required the use of a 'goto.' That is
not because I was making any special attempt to avoid the 'goto' although
the term has passed out of my lexicon. It is because I found no _elegant_
reason to use one. Even a Turing machine, as the simplest and most
fundamental of state transition systems, can be coded easily and efficiently
without using a goto.

This is not a common kind of algorithm, of course, but it's a legitimate
one. Naturally, you have to be careful how you code it.

I would certainly agree that state-transition systems are legitimate. I
would disagree that 'goto' is required in order to implement them.

We don't want to teach knee-jerk programming, where programmers
automatically do one thing because they've been told to, not because
they've considered the alternatives.

Engineers don't consider the use of toothpick to build highway suspension
bridges. Does that make them 'knee-jerk' engineers because they didn't
consider the use of toothpicks? If the obvious and common constraints of a
system leads you away from some common mechanisms, is it wrong to start by
excluding those mechanisms early? You have to combine the desire to
consider alternatives with the desire to reach a reasonable conclusion in a
reasonably short period of time.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Michael A. Covington]

Minor correction: I did not call anyone stupid. I did call the folks who

use goto "slackers" and "luddites".

There may indeed be such people.

I maintain that there are no algorithms that REQUIRE this simple structure
(I may be wrong on this point).

I believe Dijkstra proved that that is so, at a very early stage.

I gladly concede that there are algorithms that can be made more efficient
with the use of this construct.

Or, more to the point, easier for human beings to understand.

Knuth pointed out back in 1974 that the point of structured programming is
not the elimination of 'goto' but the restriction of transfers of control.
If you use 'goto' in a disciplined way, it does not introduce unreliablity.
See this link: http://portal.acm.org/citation.cfm?id=356640

I should add that Knuth's masterpieces, TeX and Metafont, are highly
structured and I don't know if they contain any 'goto's at all; if so,
certainly not many. But he stands up for his *right* to use them.

That depends on what you mean by 'better.'

I mean that the algorithm is easier to understand, easier to confirm the
reliability of, and easier to maintain because of the use of a 'goto' than
it would be if it were pieced together out of structured programming
constructs. It is also a tiny bit more efficient, but that's not a big
thing because the compiler optimizes.

Such algorithms do exist. They were discussed extensively in the early days
of structured programming, and that is why all structured languages - up to
and including C# 3.0 - still have a 'goto' statement.

By the way, I don't like the C language at all. By relying on unchecked
pointers, it does to memory what 'goto' does to program organization --
opens up a whole can of worms! (Including computer security holes that have
led to tremendous damage. Why should there ever have been such a thing as
buffer overruns?)

I come out of the Algol and Pascal tradition and like C# mainly because it
combines the conciseness of C with the reliability (at last!) of languages
that manage memory properly. And I dislike 'spaghetti code' as much as you
do.

 

[Michael A. Covington]

Much closer to home, here's what Steve McConnell (of "Code Complete") says:
http://www.stevemcconnell.com/ccgoto.htm

Basically an extended demonstration that 'goto' has its legitimate uses.

In particular, he shows you some algorithms where "Use no gotos" conflicts
directly with the principle "Only express each idea once". Duplicate code
is bad because your two expressions of the same idea may not be identical,
especially if, later on, you have to maintain the code; you may not succeed
in keeping them in sync.

 

[david]

Many things are included in programming languages for purposes that do NOT
apply to new code development. While I cannot and will not speak for C#, I
can say that considerations such as backwards compatibility with similar
languages is a factor in language development. If by including a statement,
the language can be used more easily to port 1,000,000 lines of C or even
Cobol code, then the statement is valuable, even if no one is using it for
new coding.

There's another issue too, which is code generation. On the one hand I
could say that I've not written a goto in C# or C++, but the truth is
that I've used lex/yacc/antlr and those tools have generated goto
statements.

Now this isn't code that's meant to be human readable. The goto
statements don't show up in the source tree and aren't reviewed in
code review. But parser generators are a lot more elegant to write if
the destination language has a goto or equivalent.

 

[david]

Much closer to home, here's what Steve McConnell (of "Code Complete") says:
http://www.stevemcconnell.com/ccgoto.htm

Basically an extended demonstration that 'goto' has its legitimate uses.

Actually, I think the most pertinent statement from McConnell here is:

"These articles contain the whole goto debate. It erupts from time to
time in most workplaces, textbooks, and magazines, but you won't hear
anything that wasn't fully explored 20 years ago."

Except that at this point, it's over 30 years ago.

I must admit though, it's been decades since I've seen the kind of true
spaghetti code that was pretty common back in Dijkstra's day. Unless
they're in certain specialized environments (assembly, batch files),
I suspect most younger programmers have never seen *real* goto-filled
spaghetti code. In my experience, even truly bad programmers today
don't write that kind of stuff, it simply doesn't occur to them to try.

Of course, I don't work in COBOL shops, though

 

[Jimbo]

Can I just congratulate the participants for some intelligent discussion
that steered clear of flame wars that opposing views often result in. I
can now honestly say I've learnt something new about both points of view.

Cheers
Jimbo.

 

[Bob Powell [MVP]]

Goto's are not evil because they have a specific place in even a structured
program. Searching my massive library of code that I've written over the
last six years I find that in all the C# files I've used goto about a dozen
times. Once in a console application to go to an error / usage display block
which ended the program immediately and the rest of the time for overcoming
the problem C# has with falling through cases which was useful in C++, the
"goto case" construct.

Generally an engineer who understands structured programming rarely has a
need to use direct branches, goto statements, in any case. Good programmers
use the facility very very sparingly. Goto is the last resort of the
educated and the first resort of those who don't have a clue.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Peter N Roth]

The goto, a Japanese musical instrument, is not evil.

Goto, the statement, is not evil either. Preferred euphemisms
are 'break', 'continue', & 'return'.
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET

 

[HC]

Which is cleaner?

GOTO
for a = 1 to LengthA
for b = 1 to LengthB
for c = 1 to LengthC
for d = 1 to LengthD
do_stuff(a,b,c,d)
if discontinue then goto GetOut:
next d
next c
next b
next a
GetOut:

NO GOTO
for a = 1 to LengthA
for b = 1 to LengthB
for c = 1 to LengthC
for d = 1 to LengthD
do_stuff(a,b,c,d)
if discontinue then break
next d
if discontinue then break
next c
if discontinue then break
next b
if discontinue then break
next a

 

[Scott Roberts]

I know one common use people say is for getting out of deeply nested
statements but you can easily do without gotos by using booleans or replacing
sections of code with function calls.

It seems that the people who don't know "goto" should be avoided also don't
know that "deeply nested loops" should also be avoided!

I've rarely seen a case where "goto" is necessary. I think that most cases
are probably for optimization, but if you're needing that much optimization
you probably shouldn't be using C# in the first place. I won't say "goto"
should *never* be used, but I've never used it myself. Never had the need.

Now, for a really interesting debate, let's talk about the form of "goto"
stealthily named "return"!

 

[Scott Roberts]

I think the OO mindset of treating long methods with complex flow
control as a code smell probably contributes to a style of programming
in which the issue does not occur.

Well said.

 

[Peter N Roth]

I would probably write something like

bool found = false;
for ( int a = 0; !found && a < ALength; ++a ) {
found = FindOnB(a);
}
// use 'found' somehow

with similar small loops in FindOnB(), FindOnC(), etc.,
because I prefer to avoid nesting loops.
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET