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



In a display file if I need to setup some indicators. I'll generally put
that code in a subroutine. Making it a sub procedure doesn't gain me
anything. I'm just "playing with the twiddly bits" Hope I got that right
Jon. I don't want that in the mainline, but see no need for a procedure do
it. As stated this is all opinions. I have a hard time convincing my boss
to ever let me use sub procedures unless I need to actually return a value
from them. That is the local standard, If it is not returning anything
subroutines have always worked, why change them. If it does return
something to you, OK you can use it. This is an advance from when I got
here, so incrementally we are getting more advanced in our coding, as the
whole group catches up.



"albartell" <albartell@xxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
08/10/2007 02:52 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

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