Hello,
What's wrong with this, apart from being ugly code? I was told that a
GOTO indicates poor analysis.
What's different with using a DO loop with ITER or LEAVE, a SUBR with LEAVESR?
I don't like discussions like this. Maybe I've been on this mailing list
too long, but discussions like this usually result in very long,
unproductive headaches.
Are you really interested in discussing why GOTOs are bad? Or are you
really and truly just looking for a way to justify why they are okay?
From the perspective of the software developer, one of the most
influential events of all time was the letter written by Edsger Dijkstra
to Communications of the Association for Computing Machinery (CACM) in
1968, titled "Go To Statement Considered Harmful". Google it and read it
-- this letter has had a huge impact in shaping the sort of programming
languages we have today.
There was a time before this letter when GoTo was one of _the_ most
widely used operations in all of computing. Programs really had no
structure at all -- they'd be constantly jumping around to random places
-- and code like that is really hard to maintain. The flow of the code
was very difficult to unravel, much like trying to unravel all the
twists and turns of the noodles on a large plate of spaghetti -- and
that's why we have the phrase "spaghetti code."
It was largely due to this letter, and people's reactions to it, that
computer languages evolved, and structured programming (and eventually
object-oriented programming) became popular. It's the reason why we
have block opcodes like IF/ENDIF, DO/ENDDO, etc. Without this letter,
we almost certainly wouldn't have.
For those that haven't had to deal with spaghetti code created by a GOTO
mess, it's a little hard to imagine how frustrating, time consuming, and
awful it can be to work with. For those people, they see themselves
saving some time by coding one or two GOTOs in a program, and then they
say "Look, I added these GOTOs, and you can still read my code! Gotos
aren't bad." Yeah, that's because you only have one or two.
Here's the thing: Well-written program code "tells a story". It should
be structured in an intuitive way that's easy to follow. It should be
easy to follow because it's structured to follow a logical sequence of
events that will make sense to the programmer that's reading it.
Loops, ITER, LEAVE, LEAVESR, and RETURN may seem a bit like GOTO, and
they are to an extent, but their destinations are well-known and
intuitive destinations. "Get me out of this loop" or "get me out of
this routine". Your code still tells a story.
But, GOTO, if you are allowed to use it any way you wish, has far more
freedom to make the code unreadable. It allows you to break out of one
part of the story, jump into another part of the story, spend a moment
there, then jump out again into yet another part of the story, and maybe
even jump back to where you left off. IT no longer follows a logical,
easy-to-follow, flow of events because it can (potentially) jump
haphazardly around.
I suppose that instead of saying "Don't use GOTO" you could make a rule
like: "Only use GOTO where it allows your program to be easy to read and
follow a logical flow of events". The problem with that is... everyone
has a different opinion of what's easy to read. If you had a rule like
that, you'd essentially be saying "it's okay to use GOTO willy-nilly",
since there's really no way to force programmers to keep their GOTOs to
a level that you consider "readable."
The thing is: GOTOs are unnecessary. If your code is well-structured,
you can always use an IF/ENDIF, DO/ENDDO (possibly with LEAVE or ITER)
or RETURN/LEAVESR to accomplish the same thing in a much cleaner way.
If you find yourself wanting to use a GOTO, most likely, you aren't
paying enough attention to making your program want to "tell a story".
Or to put it another way: You aren't designing the flow of events in
your program in a way that handles the true flow of events. Most
likely, because you aren't event thinking about it.
midrange.com
