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