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


  1.  Home
  2. RPG400-L
  3. August 2007

RE: Todays WTF

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.

But you are making assumptions in my argument. Yes, it is obvious a sub
proc couldn't call that sub routine in the mainline. I wouldn't have
created a sub routine if I wanted that piece of code to be called from a sub
proc.

I think what we are essentially looking for is a list of reasons to go sub
proc vs. sub routine. A list like that would be very weighted towards
personal opinion. For instance, sometimes I like sub routines simply
because sub procs take at least twice as long to code. That is a case where
I would use a sub routine if I didn't need local variables.

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 2:41 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Todays WTF

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.


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