× 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: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Mon, 21 Jul 1997 10:02:08 -0400

Lloyd,

>On Fri, 18 Jul 1997 15:24:47 -0400, Buck Calabro
><mcalabro@commsoft.net> wrote:
>
>>The point of this discussion was to suggest possible ways to use structured
>>code; to avoid the GOTO.  I understand that the *current* language definition
>>requires me to have matched BEGSR ENDSR pairs.  I'm suggesting a change
>>to that specification..
>>
>>Other folks in the discussion were suggesting a new opcode to "leave a 
>>subroutine early."   I just thought that we already have a "leave 
>>subroutine" (ENDSR) opcode; why not simply reuse it for the case when 
>>we want to leave early?
>
>Being totally serious here, do we also want multiple ENDDO/ENDIF ops
>so we can terminate our loops and conditions early? The last thing I
>want to see when looking at someone else's code is an END* when it's
>really not ending, ie, not the end of the structure. The whole point
>is to (easily) determine where a structure begins and ends. This is
>even more important with fixed-format (non-indented) code..

Nope, I wouldn't want that, but then I didn't suggest that, either! <grin>

>In terms of programming logic, a GOTO *ENDSR or LEAVSR variant is
>totally acceptable, it's the same implied thinking behind
>LOOP/LEAVE/EXIT - we're terminating the structure early..
>
>Some will comment that "if you code correctly, logic will fall through
>to the end". In strict textbook/structured programming terms, that's
>okay, but in terms of practicality I'd rather have LOOP/LEAVE/GOTO
>with a comment stating why instead of conditioning everything in my
>structures "just to" make it fall through. It can hamper readability
>and maintainability..
>
>In terms of the above, using GOTO does not lead to spaghetti code but
>overcomes a limitation of the language. In this case, the need to exit
>a subroutine early..

I rather agree with every point you've made...  Following your thoughts
on practicality and readability, it didn't seem that hard to understand:

CONDITION IFEQ TRUE
                    ENDSR
                    ENDIF

Since it seemed simple and readable (to me) I tossed the idea out for
comment...  Your remarks on balancing readability and practicality
are an excellent synopsis of the problem of writing code in general.
Well put!

Buck Calabro
Commsoft, Rensselaer, NY
mcalabro@commsoft.net

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