Re: Long Procedure Names -- RPG400-L


Hi John,

[SNIP]

CUGLS001_getLastPeriod()
CUGLS001_getLastClosedPeriod()
CUGLS001_getPeriodStatus()
CUGLS001_getPeriodStatusDesc()

This is much easier to read than your abbreviations, IMHO.

[SNIP]

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 always found it difficult to articulate why I prefer free format RPG to fixed format. People always seem to assume that it's because of indenting -- but that's always been a minor thing to me.

SPACE is exactly what makes free format attractive. Your examples are PERFECT description of why I prefer free format. Trying to code meaningful subprocedure and parameter names in fixed format is nearly impossible!

I'll assume that you're already using free format -- if you're not, though, please consider switching to it. That'll free up about 30 characters that you're wasting with fixed format.

The other strategy that I've found useful is something that I learned from reading Carsten Flensburg's code. I didn't like it at first, but after awhile it grew on me! :) The idea is, if the subprocedure call doesn't fit on one line, put each parameter on a separate line. Put the colon that separates the parameters at the start of the line.

For example:

        CUGLS001_getPeriodStatusDesc( currentCompany
                                    : periodName
                                    : periodStatusDesc
                                    : someOtherParm    );

Having said that, it DOES help to try to keep your variable names shorter. By that, I don't mean use cryptic abbreviations, but you don't necessarily have to write out every word, either.

For example "curCompany" is probably just as good as "currentCompany", and saves you a bit of real estate. Likewise, "perName" and "perStatDesc" are probably good enough. Certainly a lot better than the "pdStsD" that we used in RPG III.

But, then you start using qualified data structures, and it gets much much worse than even the examples that you listed.

        CUGLS001_getPeriodStatusDesc( ThisYear(periodNo).CompanyName
                                    : ThisYear(periodNo).periodStatusDesc );

If you take it a step further, and nest data structures within data structures, it REALLY gets nasty:

        CUGLS001_getPeriodStatusDesc(
                 ThisYear(periodNo).CompanyInfo.CompanyName
               : ThisYear(periodNo).PeriodStatus.Description );

Of course, it's not any easier to make this stuff look good in Java than it is in RPG. virtually every Java program that I've seen does all sorts of wrapping variables in strange places. So, I guess nobody has found any great solutions to these problems yet.

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.

You don't need to use procedure pointers. EXTPROC() will do what you want to do without using pointers.

     D getLastPeriod   PR                  ExtProc('CUGLS001_GETLASTPERIOD')
     D   parm1                        1A
     D   parm2                        1A

However, I do agree that this is both ugly and violates the rule about defining prototypes in only one place. I think it's better to keep the subprocedure name long, and wrap the lines as I demonstrated above.

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.

I've been complaining about that for a long time. Not for shortening subprocedure names, but for call-backs! I hate that whenever I want to use a procedure pointer to call a procedure, I have to re-define the prototype, and maintain two prototypes. There's also no syntax checking to enforce that when a procptr is passed as a parameter that it points to a procedure with the correct parameter list. Also, I'd like to be able to nest a prototype into a qualified data structure so that you can have myDsName.ProtoName(parm; parm) on your C-specs...

Barbara tells me that they've had a LIKEPR keyword on their wish list for awhile, but haven't thought that it was a priority.

I'm now looking for fresh ideas. What are the rest of you doing to tackle
this problem?


Mainly, just three things:

   a) Use free format RPG.
   b) If it doesn't fit, put each parameter on it's own line.
   c) Try to keep your names as short as possible without using
           cryptic abbreviations.