I use subroutines within subprocedures to section out (generally
reusable) code not specific to the procedure at hand. I suppose you're
essentially saying the same thing, but in the case that the subroutines
are in the mainline. For me, I personally prefer procedures as a rule
of thumb with subroutines requiring extra justification.
sectioning out reusable pieces of code that don't have local variables.
This statement alone doesn't seem to justify a subroutine. By this
logic I could have a subR that initializes global variables. My point
is that by doing that, now a subP couldn't call that code. That's where
I was coming from in my last response.
I wouldn't ever suggest black and white coding. ;)
Kurt Anderson
Application Developer
Highsmith Inc
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Friday, August 10, 2007 1:45 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Todays WTF
For the same reason Joe mentioned. Using sub routines at the mainline
level can have the same benefits of sub routines in a locally defined
sub proc - sectioning out reusable pieces of code that don't have local
variables.
Going black and white to say that sub routines should never be used
because we have sub procs is bad practice IMO. I place emphasis on the
fact this is my opinion. If you don't agree we can just move on from
this because like others have said this exact same argument has taken
place many times in the forum.
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kurt Anderson
Sent: Friday, August 10, 2007 1:17 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Todays WTF
Aaron,
Why would you want to mix procedures and mainline subroutines in one
module (other than *InzSR or *PSSR). If you're going to tuck away code
somewhere, why not make it accessible by prototypes (since prototypes
can't call subRs outside of its scope)?
Kurt Anderson
Application Developer
Highsmith Inc
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Friday, August 10, 2007 11:28 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Todays WTF
For the record, and to repeat what I said in my previous email more or
less, I agree with your refined statement of sub routine usage. I
pretty much only use them when I DON'T need local variables and instead
the code uses entirely global variables. With that said I only use
global variables when it makes sense.
Now, if sub procedures became entirely free format and didn't require a
prototype I would probably use them as a complete replacement for sub
routines.
Thanks for expanding on your reasoning,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Steve Richter
Sent: Friday, August 10, 2007 11:20 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Todays WTF
On 8/10/07, albartell <albartell@xxxxxxxxx> wrote:
I agree with your definition of how sub procs helped your situation
and that is the same approach that I took. That still doesn't address
your original comment of putting sub routines with the likes of
GOTO's, but if your re-definition below serves as a sort of retract to
say sub routines can SOMETIMES be beneficial then I will just drop my
challenge.
Aaron,
complexity = a lot of details. details are details, no matter the
origin.
When you are reading code that contains a GOTO, the unimplied return
point of the GOTO is one more detail you have to keep track of.
When the subrtn uses a global variable that is assigned to in one
routine and then used as input 3 routines down the call stack, that is
another detail. The end result, is a pile of details that unnecessarily
bog down your work.
-Steve
--
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.
--
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.
--
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.
--
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.
midrange.com
