|
hi Darren,years
It's hard to say whether you're doing it "wrong," since I have only a
high-level description of what you're doing.
In my experience, when a subprocedure has too many parameters, it
usually indicates that the procedure is trying to do too many things.
IMHO, a subprocedure should just do one thing -- and when the time comes
to do the next thing, a separate procedure should be used. However,
it's very difficult (for me, at any rate) to describe what constitutes
"one thing."
And, there are certainly cases where a lot of data is required for just
one thing.
Nesting data structures inside other data structures is a relatively
simple solution -- but I find that when I do that, I have to work hard
to keep the DS names short -- otherwise, it becomes very difficult to
deal with the nested DS, the names quickly become too long.
On 7/24/2012 9:40 AM, darren@xxxxxxxxx wrote:
I have been using sub procedures exclusively in my code for about 3
numbernow. One things that I continually have trouble with is a growing
allof parameters that I pass around. If one procedure gathers a bunch ofdata
and a couple different sub procedures need to process with that data,
meanof that data has to be declared and passed. I'm talking about data
structure data, so lumping the variables into a data structure would
listdata structures within data structures. I've done this data structureWhat I
nesting before and it looks confusing when I come back to it later.
find myself wishing for is variables global to the current call level.
This could be accomplished with local subroutines I'd guess.
Am I doing it wrong?
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
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 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.