RE: Indicators

["Bruce Guetzkow" <bruceg@xxxxxxxxxxxxxxxxxxxxxxx>]

This sounds like an area where there isn't a standard (or at least it
isn't clear).  IMHO, the worst situation would be having a source member
with both subroutines and sub-procedures in them.  While functional,
this would be confusing.

Since there is a difference of opinion, possible solutions might be:
- if source has subroutines, continue to use subroutines
- if source has sub-procedures, continue to use sub-procedures
** or **
Perhaps an edict from the Standards-God to use one or the other?  It
would seem logical that someone needs to make a decision at some point,
or agree to disagree.

I have the distinct advantage of being the development team, so when I
encounter a situation, I can make a decision and stick to it until I
decide something else is better, at which point I make another decision.
I have been in your situation as well and don't lightly make the "edict"
case.  Sometimes, however, that is the only way...even if it isn't my
method that is chosen.


>from: "Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxx>

>We do have a group of developers/Managers that govern and set standard
for the shop.  The example you have about setting standard for >/free is
pretty straight forward.  However, it is not the case for sub-procedure.
Some developers like sub-routine.  For them sub-
>procedure is not as readable as sub-routine.  And of course, there is
another group that think sub-procedure is better and more
>readable.  What you end up with is one group keep pushing sub-routine
into program and the other keep pushing sub-procedure.

FWIW...
Bruce Guetzkow
Information Services Director
United Credit Service, Inc.
Phone: 262-723-2902
Fax: 262-723-5568
Email: bruceg@xxxxxxxxxxxxxxxxxxxxxxx
Web: www.unitedcreditservice.com