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


  • Subject: Re: Additional RPGLE Enhancement Requests
  • From: DAsmussen@xxxxxxx
  • Date: Tue, 22 Jul 1997 00:58:10 -0400 (EDT)

Booth,

In a message dated 97-07-14 12:20:17 EDT, you write:

> Sorry Dean, but I am having a great emotional battle over this.  I know
>  that GOTOs have become the antiChrist, but I have seen too many DOWxx and
>  DOUxx with their associated "END" hundreds of lines away.  The chances of
>  figuring out exactly what the programmer was trying to do has long since
>  disappeared.

I know, but GOTO's get EVEN WORSE.  If David had the bandwidth and I had the
legal right, I'd be glad to send an example of an order entry program that
branches past a huge chunk of logic and then BACK UP INTO IT several times.
 Your "END" hundreds of lines away is poor code as well, but at least it's
linear when you're trying to debug it for the first time!

>  I won't vent my feelings toward a program who's first C line is " *INKC
     
>  DOUEQ*ON "  with it's "ENDDO"  800 lines or more later, followed by " MOVE
>  *ON      *INLR ".  But I will say that strikes me as convoluted and
>  muddifying.  Is "muddifying" a word? Anyway, "to make muddy, unclear,
>  layered in obfuscation" would be the meaning.

Actually, I think you had it in "obfuscating", but I LIKE "muddifying"!  Bad
code is bad code but, IMHO, GOTO's make it "bad spaghetti".

>  Bad logic and bad division of the job into its pieces is poor programming
>  whether the programmer used GOTOs or DO_xxs, imho.

Agreed 100%.  I just think that conditional GOTO's introduce the possibility
of "dead" code that never gets executed.  That "dead" code didn't take me any
less time to debug on paper than the code that was actually causing the
problem.  In fact, I just spent a day and a half trying to figure out how in
the heck the condition got met because I'm SURE that my problem originates
from the "dead" code area...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"One of the greatest labor-saving inventions of today is tomorrow." --
Vincent T. Foss
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.