× 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.



This is one of those e-mails that I will save in my special folder
Some people here STILL use GOTO's
Sends me up the bloody wall

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, September 10, 2012 11:04 AM
To: RPG programming on the IBM i / System i
Subject: Re: GOTO in free form!

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.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.