× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.