what's the prob with goto

[Vishal Naidu]

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

 

[Muni]

Even though goto were not used directly, but they are implicitly part
of control constructs of a programming lang.

gotos would reduce the redability of the program. If the programming
spanning across pages, it owuld be really difficult to understand the
programs with gotos.

 

[Richard Heathfield]

Vishal Naidu said:

i m new to the C world...

i ve been told by my instructors not to use goto stmt..

A wise student obeys his instructors unless he knows them to be wrong.

but no one could give me a satisfactory answer as to why it is so..

Not all instructors understand the advice they give. That doesn't
necessarily mean it is bad advice.

plz help me out of this dilemma, coz i use a lot of goto in my codes....

The problem is that goto doesn't scale well. The more you use it, the harder
your programs will be to maintain, because the flow of control of your
program becomes harder to read. This phenomenon is known as "spaghetti
code", and with good reason.

In many organisations, goto is actually banned altogether. So it's a good
idea to learn how to program without it. Once you have done so, you'll
wonder what you ever saw in it.

 

[John Bode]

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

Bad structured code is orders of magnitude easier to debug and maintain
than bad unstructured code.

You shouldn't need to use goto very often. One problem with using goto
is that it can destroy the ability to debug code by inspection. It's
not so much the goto itself that's the problem, but rather than the
uncertainty introduced in the code around the target of the goto. For
instance, given the code fragment:

i = 7;
label: printf("%d\n", i);

What value gets printed for any particular path of execution? Until I
account for every instance of "goto label;", I don't know. I have to
trace all possible paths of execution before I can say with any
confidence what gets printed under what conditions. This makes code
harder to debug and maintain. God forbid I have to make any changes,
because I can't say with any confidence that any change will not
inadvertantly affect *some* path of execution.

The story I like to tell is one program I stumbled across early in my
career written by an electrical engineer. A 5000-line main() function,
with something 15 gotos, some of which branched forward, some backward.
It took my co-worker two full weeks to figure out how the damn thing
actually worked. We were tasked with improving performance of the app,
but anything we did simply broke the code. We finally recommended that
the customer just buy faster hardware; it would be cheaper than the
effort to make the code faster would cost.

Now, that particular application was pathological beyond the use of
gotos, but they made a bad situation impossible. Had the code been
somewhat structured, we probably could have made some improvements.

Gotos are useful in a limited set of circumstances, like when you need
to break out of a deeply nested loop, or need to make sure some cleanup
code runs before exiting a routine. But they should not replace
control structures like if-else , for, while, do-while, or switch
statements.

If you're going to use a goto, make sure you branch forward *only*, and
that you do not branch into a block.

 

[Ian Malone]

The problem is that goto doesn't scale well. The more you use it, the harder
your programs will be to maintain, because the flow of control of your
program becomes harder to read. This phenomenon is known as "spaghetti
code", and with good reason.

In many organisations, goto is actually banned altogether.

<snip>

But that's okay, because you can achieve similar functionality with
a for loop, a switch statement and liberal application of control
variables. <g>

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

Please read "Goto Statement Considered Harmfull" by Dr. Dijkstra, in the
"Communications of the ACM". You can find a public version of this paper at
http://www.acm.org/classics/oct95/


- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDFu44agVFX4UWr64RArKPAJ9XQL0H+A5gRyx3qECnM38veR4RjACeIdks
lhUo4XErlOIavJP/3iqLmQk=
=j7B8
-----END PGP SIGNATURE-----

 

[ajm]

Vishal,

John's point about goto into a block is real important, for example if
you skip past the initialisation of certain local variables then the
results can be "undefined" - e.g., static local variables. The C
reference manual (and doubtless other publications) make specific note
of this issue so you have been warned

ajm.

 

[Eric Sosman]

Vishal,

John's point about goto into a block is real important, for example if
you skip past the initialisation of certain local variables then the
results can be "undefined" - e.g., static local variables. The C
reference manual (and doubtless other publications) make specific note
of this issue so you have been warned

The warning is good, but the detail is not: a static
variable cannot be uninitialized, and furthermore its
initialization occurs before the program starts and thus
does not depend on the run-time flow of execution. The
problem ajm mentions afflicts auto and register variables,
but not statics.

 

[ajm]

apologies! yes of course that is what I meant to say (statics are
handled entirely differently as Eric points out)

 

[osmium]

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

If the instructor had taught the course properly you wouldn't be using a lot
of gotos, because you wouldn't even no the stmt existed till the last day of
the course.

 

[Ben Pfaff]

Vishal Naidu said:


A wise student obeys his instructors unless he knows them to be wrong.

A wise student seeks to know *why*, not merely *what*.

Not all instructors understand the advice they give. That doesn't
necessarily mean it is bad advice.

An instructor that cannot justify his own advice is likely a bad
instructor.

 

[Ben Pfaff]

Please read "Goto Statement Considered Harmfull" by Dr. Dijkstra, in the
"Communications of the ACM". You can find a public version of this paper at
http://www.acm.org/classics/oct95/

For a more balanced point of view, see Knuth's _Structured
Programming with go to Statements_.

 

[Randy Howard]

Richard Heathfield wrote
(in article

Vishal Naidu said:


A wise student obeys his instructors unless he knows them to be wrong.

And a brilliant student will /still/ want to know the reasons
behind the advice.

Not all instructors understand the advice they give. That doesn't
necessarily mean it is bad advice.

True, but not a justification for blindly following it. There
are probably professors that show the use of void main() as well
in their examples.

The problem is that goto doesn't scale well. The more you use it, the harder
your programs will be to maintain, because the flow of control of your
program becomes harder to read. This phenomenon is known as "spaghetti
code", and with good reason.
Agreed.

In many organisations, goto is actually banned altogether.

Very true, thanks in no small part to a famous paper on the
subject, entitled "Go To Statement Considered Harmful", written
by Dijkstra and published in ACM way back in March of 1968.
That's how long this debate has been raging. There are also
similar, but not identical copies of this paper with a different
title "A Case against the GO TO Statement" what appeared as 'EWD
Manuscripts'.

Of course, there are also those that thing that he overstated
the case, resulting in a lot of people blindly following the
admonition without understanding why. Ironic, that.

See also, "Flow Diagrams, Turing Machines, and Languages with
only two formation rules," C. Bohm & G. Jacopini, , ACM May
1966.

David Tribble does a good job analyzing and commenting on it
here:
http://david.tribble.com/text/goto.html

So it's a good idea to learn how to program without it. Once you
have done so, you'll wonder what you ever saw in it.

Possibly. There are cases where it is difficult to avoid, and
might produce a more readable result than some attempt to not
use it. The use of setjmp/longjmp isn't much different either.

In some deeply nested loops (which I don't generally recommend)
it may also be necessary.

I would say that the goto statement is best avoided, but to not
necessarily adopt the view that it /must/ be avoided in all
cases. Blindly following good advice may be slightly better
than blindly following bad advice, but that doesn't mean blindly
following anything is a good idea.

 

[Chris Hills]

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

This came up on the high-integrity discussion group the other day. It
was discussed by two leading and well known people in safety critical
software.

Apparently there is no empirical evidence that goto is harmful. There
was one study but I think it was not seen as valid. Though it did show
that bug count was proportional to the number of gotos!

The problem is more subtle. You can recognise good or "clean" design in
physical objects but can't quantify why. Quality is recognisable but
difficult to quantify. Software is, like painting, sculpture, music
part technique (that has to be practised, masters and rigorously
applied) and part art.

Similarly experienced practitioners (like master craftsmen) know/feel
goto is bad but can't really give you a hard and fast mathematical or
solid logical reason.

The can give valid examples but so can the naysayers.

Generally you should use the "normal" flow control statements. If while
do switch.

This implies that you have to think about the design of the code.
Software Engineering is about designing the program. When it is designed
then you write the code.


Remember all entered apprentices need to learn techniques. Often the
need to master these techniques before the reasoning falls into place.
The explanation will not make sense until you have got to the point
where the answer is clear without asking. Before that point the answer
will not make sense.

 

[Christian Bau]

i m new to the C world...

i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..

plz help me out of this dilemma, coz i use a lot of goto in my codes....

1. Using corrupted English like "plz" and "coz" is considered to be
absolutely uncool amongst most readers here.

2. Not using goto's will help you become a better programmer. Whether
your instructor can explain why doesn't make a difference.

3. At some point you will hopefully be wise enough to recognise the rare
situation when using "goto" is better than not using "goto". But if you
have to ask whether to use it or not, then don't use it.

 

[Richard Tobin]

2. Not using goto's will help you become a better programmer. Whether
your instructor can explain why doesn't make a difference.

Acquiring a frame of mind in which you naturally use some other control
mechanism except in rare cases seems like a good thing.

But if instead you translate the gotos that seem natural to you into
something else, you may just end up producing more buggy code.

I suppose the forced discipline of not using gotos may eventually help
you to acquire the right intuition, but being taught *why* they're
usually bad seems like a more straightforward approach.

-- Richard

 

[Peter Nilsson]

1. Using corrupted English like "plz" and "coz" is considered to be
absolutely uncool amongst most readers here.

Well, what is 'uncool' if not corrupted English? Sure, it's made
several
dictionaries, but then so has 'pls'.

It's not the 'cool' factor that's at issue. It's that such terms
make it that little bit more difficult to read the posts, hence
they reduce the likelyhood of people focusing (or even bothering)
with the question at hand.

OP's should consider plain English communication (at least in clc),
along with actual source code illustrating the problem, as a sound
investment, if not simple courtesy.

 

[Peter Shaggy Haywood]

Groovy hepcat Richard Heathfield was jivin' on Thu, 1 Sep 2005
09:40:36 +0000 (UTC) in comp.lang.c.
Re: what's the prob with goto's a cool scene! Dig it!

The problem is that goto doesn't scale well. The more you use it, the harder
your programs will be to maintain, because the flow of control of your
program becomes harder to read. This phenomenon is known as "spaghetti
code", and with good reason.

I've said it before and I'll say it again. Meatball programmers
write spaghetti code.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Richard Heathfield]

Ben Pfaff said:

A wise student seeks to know *why*, not merely *what*.

ITYM A wiser student. I was working on the basis that most students are not
as wise as all that. ;-)

 

[Marc Boyer]

An instructor that cannot justify his own advice is likely a bad
instructor.

Not the best one, yes, but to the worst.
I prefer "no justification" to "wrong justification".

Marc Boyer