Are gotos truly evil?

  • Thread starter Thread starter Guest
  • Start date Start date
Peter N Roth said:
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.

I think many people hate you, but you wander through life not realizing
this. Perhaps your ghost will cry when it looks upon the empty room that
is your funeral.
 
Google "spellchecker"

ibluesun said:
Hi :)

I would like to deffereniate between two goto's statement

goto in old days
and
goto in current days

I used to program BASIC at MSX
goto was an important statement for the language
because you don't have functions :)

and to simulate functions another statement was GOSUB

I think the dangerous of goto is disappeared in any procedural language

BASIC (and also Assembly) is not considered to be procedural language

means that goto statement could throw you in any code in your program.

but try to make anonymous function in C# 2.0 and make a goto statement that
is outer the boundary of it immediately the compiler will refuse to compile
:(

in my opinion the goto bad reputation was inroduced as an effect of the old
days programming
remember you were only coding in
- ONE FILE
- ONE piece of code ( which your enrty point was the first line of code and
the end was at the last )

I have a fortran program written by my proffessor to solve something about
thermodynamics stuff. I got astonished about the amount of the goto statement
in it, But suddenly I knew why he was using it. The calculations where
accumulated and he needs to make some sort of testing at every stage so he
was using goto to transfer the program to the end line.

I don't consider goto statement is an evil unless the numbering come
back to any language [ may be thats why labels inroduced in the procedural
language ]

in another way you CAN'T goto from CLASS A code to CLASS B code with out
instantiating the two classes and know a set of methods to call

its all about transferring the current control to another control

so goto nowdays is really really limited to the their block of code

I don't make a huge lines in one method
instead I make many many few methods which I suddenly discovered that it is
unreadable

so if you see goto statement in c# don't panic as it is not the no.1
source of complexitiy and I repeat it is only affecting its enclosed block
{} unless you are typing all of your program in the main() :)

goto is very romantic statement it makes you escape from your
responsibilities and it expresses our weakness as a human being if there is a
program without an ERROR then I might be wrong :)



--
BLUE SUN


Mark R. Dawson said:
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.
 
Summary: Gotos are a tool: useful but dangerous

Mark R. Dawson said:
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 had a teacher like that once:
"I have never had sex in my life, one of the first things I was told in
my sex ed class, last semester, was, 'Sex will give you many diseases
and boys won't respect you - don't have sex!'"

I have used gotos. I have had down and dirty gotos and prim and proper
gotos. I have used gotos for Evil (for looping; a Very Bad Idea)! I have
used gotos for Virtue (one exit per function - read Myers' books). I
have written assembly code, batch files (shell scripts to the eunuchs) I
know gotos.

A lesson to the New Programmers:

Preface:
When there was no concept of "germs", doctors would operate on a patient
without washing. Or operate on several in a row. No soap, no mask, etc.
Then a guy came along to try to convince these guys that there were
little invisible aliens that sat on their hands and pushed disease into
the patient. If the doctor coughed or spat, some "germs" might infect
the patient! Ha! What?! Seriously? Nah.

History:
When programmers were first making programs without functions, therefore
no returns, you had to jump to where you wanted to go and jump back to
where you were before. Or where you thought you should go next. Usually
using line numbers. If someone added code inside the line numbers, the
goto would have to be manually changed - everywhere. BTW, that's why
statements were 10, 20, 30, etc. Because if you added lines, you could
use 11, 12, 13 and not have to change the "goto 10" statements
everywhere. I think the kids think that line numbers were just multiples
of 10; they were not. Oh, and no #defines!

========= skim this =========
(Off the top of my head example, please don't flame about the
pseudo-BASIC provided)
Now, think upon this - you have a nice routine starting at line 502 (we
stopped using the 501 initializer in version 7.2) that you are using in
several functions to output data to the screen. About 576 there is a
useful routine for converting alpha chars to numbers, so you just JUMP
INTO THE MIDDLE OF THE PRINT ROUTINE to do a text conversion. Then use a
goto to get back, the global TC =3.

500 REM PRINT CHARACTER TO OUTPUT
501 LET X=4
502 IF CHR(C) < 65 THEN GOTO 589 ;REM NOT A LETTER
503 IF CHR(C) > 90 THEN GOTO 589 ;REM NOT A LETTER

<statements to init the printer>

GOTO 576
....
576 REM CONVERT TO LETTER
577 LET C=C-65
578 IF C > 26 THEN GOTO 589
....
588 RC=0 ;REM LETTER

589 RC=47 ;REM NOT A LETTER
600 IF TC=1 GOTO 301 ;REM TEXT CONVERTION FINISHED
601 IF TC=2 GOTO 904 ;REM STRING IS ALPHA, RETURN TO NAME_INPUT
602 IF TC=3 GOTO 1130 ;REM GO SOMEWHERE ELSE
========= skim this =========

The Spaghetti Coder:
In the Bad Old Days, there were a lot of arrogant programmers who wrote
the code they needed to do a job, using the tools they had. And they
maintained that code for its/their lifetime. Later, new programmers were
brought in, and had to learn this code - time constraints meant they
were not the "master" of the code that the original coder was. Changes
were easy to make, but hard to confirm. Much time was spent debugging.
Numbers were spread through-out the code and some came to deserve the
special distinction of "Magic Cookie". This term refers to a number
that was derived by the original programmer over many hours of research
and thought, and that makes a routine work correctly where another
number would not. Usually, it is an encryption, or protocol number that
has special properties (prime number (divided by itself and one only),
perfect number (multiple of its factors), etc.) - no one knows why it
works, but finding out why would take too much time, so just don't ****
with it. Later this term came to flavour Internet protocols, and web
pages just use a "cookie" for remembering a user. All the "magic" is
gone... sniff ;-)

As programs became larger and changes were more frequent, line numbers
became a major problem. When jumps were 20 or 30 lines away and you want
to add 50 lines of code, you have to jump to a new address space
hundreds of lines away from the code that you are modifying. And the
code around the jump is simplistic code that is really just a goto to
more code further down. You start to see code within 50 lines of each
other that refer to code 1000's of lines from each other, yet they still
refer back to some code in the 500 range (my example above, ...or below)
which starts to have REMarks around it saying things like: "Don't ****
with this code. Use 2500 for Epson printers, Use 3000 for Teletype." So
now you have "printer" code that is really only used to convert
characters to integers, with a lot of bloat around it. But you don't
know which goto goes where and the mentality quickly became, "You ****
with it - you own it!"

Meyer's Red Book:
A man came along and published some rules based on the state of the
industry. He wrote about how some of the current day's programmers were
desiring some STRUCTURE to their PROGRAMMING. He examined programs,
talked with peers, etc. and wrote a few books to try to promote the idea
of having Functions. He laid out rules that Functions should adhere to.
I will tell you now about two of them.

1. A single entry point.
New Programmers don't really understand the world before a single entry
point to a function. You could hop into a chunk of code and pop back out
at some point. Then someone changes the code and everything else breaks.
Now you have to figure out why. Nightmare!

2. One exit point.
This was a Good Idea in the time of Meyers' writings, since people were
popping in and out of code at random. The idea was, you come in run
through all the code and exit at one return point. I have worked on code
by people who still adhere to this concept and it has some problems,
namely that you must use gotos to make it work. People began to see that
it was more problematic to jump into code than to return from code when
you were done. Especially since the return part means you go back to the
code that called you instead of using a GOTO to jump to code that may
not have called you.
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.

This person has read the "good practices" of Meyers. He is older,
probably in his 50's or higher. He is not wrong in saying gotos are not
bad, but the One Entry One Exit paradigm has been modified since
everyone got on board with not jumping into the middle of functions. Not
you can leave at will.

Once functions became their own individual entities, the new paradigm is
Get Out As Soon As Possible. If you are 7 levels into an if statement
and you know you are done, you don't need to set a flag and try to
unwind that else processing - just put a "return 0;" statement - BUT, if
you have to do some clean up, then use a (forward going, same function)
goto to hit that last few statements.

if (this)
if (that)
if (theother)
goto cleanup;
else
more();
else if (drama)
{
complicated();
return ERR;
}

cleanup:
sweep();
return (0);
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.

Yes, you can "get around" gotos with booleans in all cases. But
sometimes you don't need all of that shit, you just want to go to the
label. C maxim: "Trust the Programmer"
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.

Hopefully, I have answered some of your questions.

To sum up: Use GOTO sparingly. Not for looping. Forward jumping to
"clean up code" that you would miss with a return or continue.

One last example, if you got this far:
I use goto in an Event-driven environment (Palm PDAs). Certain button
events are mimicked by keyboard buttons and "graffiti strokes", but are
handled in different event messages (ctlSelectEvent, keyDownEvent,
penUpEvent, etc). When I can I make a function that they all call, but
sometimes the code is so trivial (but I will not duplicate it - that's
bad) that a simple goto (backwards referencing, no less) seems best.
That way the goto is in the same function, a few lines away, and I can
keep the thing from getting itself into trouble. Even tho it reference
code above it, it is not looping, since it is a separate case statement.
 
Back
Top