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



Folks,
 
I'm a huge fan of service programs, and have used them extensively since
they were first made available to us. Over the years I've developed a rather
large library of them, which is making it increasingly difficult to avoid
namespace conflicts. Having realized that I needed to take a different
approach, I've tried to adopt the style I've seen here on the list, where
the name of the service program itself is used as a prefix to the procedure
name. I'm also trying to use meaningful procedure names instead of the short
abbreviated names I used to rely upon. 
 
Example:
 
A typical service program related to our General Ledger module would be
called "CUGLS001". Within this service program, I might have a number of
procedures relating to the fiscal period definitions. Historically, the
procedure names would look something like this:
 
GlRtvLstPrd() - Retrieve last period in specified fiscal year.
GlRtvLstClsPrd() - Retrieve last closed period for specified company.
GlRtvPrdSts() - Retrieve period status code.
GlRtvPrdStsD() - Retrieve period status description.
 
The trouble is that you eventually reach a point where you run out of
meaningful abbreviations. So the above procedures would now be defined as:
 
CUGLS001_getLastPeriod()
CUGLS001_getLastClosedPeriod()
CUGLS001_getPeriodStatus()
CUGLS001_getPeriodStatusDesc()
 
Generally speaking, I like this new convention much better, and would like
to continue using it. However, I've found that what I've gained in terms of
readability with the long procedure names, I'm now losing to the clutter
associated with fitting these procedure names into a short 80 char source
line. 
 
Once I load them up with meaningful parameters:
 
statusText = CUGLS001_getPeriodStatusDesc( currentCompany:
CUGLS001_getLastClosedPeriod( currentCompany ));
 
I quickly end up in a mess of continuation lines, making the code difficult
to follow.
 
I've thought about using procedure pointers to create a shorter alias name
within the consuming source member. This would allow me to keep the
"CUGLS001" prefix in the main service program, and simply drop it in those
99% of situations where "getLastPeriod()" itself would not create a naming
conflict.
 
Unfortunately, RPG doesn't offer us a "LikePrototype" keyword, so I then end
up having to maintain multiple versions of the same procedure prototype; one
for the service program proper, and another for each aliased procedure name.
Yuck.
 
I'm now looking for fresh ideas. What are the rest of you doing to tackle
this problem?
 
 
Regards, 
 
John Taylor
 
 
 
 
 
 
 
 
                       
 
 
                                                  
 
 
 
 
 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.