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



No, local variables do not make the code more bug prone because they are only applicable to the
subprocedure, and since a subprocedure only does a single thing, it isn't all that big. Therefore, a
subprocedure isn't terribly hard to read and understand. And since a subprocedure only does a single
thing, and has no side-effects, it is easy to reuse wherever it is needed; just like a BIF.

And no, global variables do not make code harder to read or modify; they make code harder to reuse.
If your program is all there to see with nothing shared in a copybook, global variables and
subroutines can be just as easy to read and maintain as a modern application using subprocedures. In
some ways easier because the change you make in a program only affects that one program. However, in
some ways this technique makes changes harder because you have to evaluate and make the same change in
more places. It is all a give and take. There is no one right answer.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Francis
Lapeyre
Sent: Monday, March 31, 2008 12:56 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: subroutines are bug factories was: Classic Traps -- I need yourinput!

Actually, in my opinion, it's the local variables that make code more
bug-prone. Why on earth do I need to keep track of what the variable is in
this or that procedure, anyway?

On Mon, Mar 31, 2008 at 11:38 AM, Steve Richter <stephenrichter@xxxxxxxxx>
wrote:

On Mon, Mar 31, 2008 at 12:18 PM, Bob P. Roche <BRoche@xxxxxxxxxxxxxxxxx>
wrote:

But *PSSR is there to handle things that are unexpected. If an error is
possibly expected, definitely use MONITOR. I also don't see the problem
with *INZSR, why get rid of a subroutine, just because it s a
subroutine?
I agree there are times when *INZSR should not be used but just to
replace
it with a named procedure, just so you don't have a subroutine, I don't
see the point. procedures and subroutines both have their uses.


Bob,

I dont think I have written a subroutine in /free, ever. The problem with
subroutines is they require global variables. Globals are bugs waiting to
happen. They make code very difficult to read and modify.
--
This is the RPG programming on the AS400 / iSeries (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.





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.