I think what you're saying (and I agree) is that the constant name
should CLARIFY the value, not simply echo it.
So if the value is 'TEA', then having a constant named 'gCSTTY_TEA' is
pointless. It merely echoes the value of 'TEA', it does not add any
level of explanation of what 'TEA' stands for... that defeats the purpose.
Even if your goal is standardization instead of clarification, it
doesn't make sense to have the constant name echo it's value. If you
standardize of TEA now, but later want to change it to PRF, you'd have a
problem: Your constant name is 'TEA' so if the value is PRF, that'd be
confusing! OR, you could change the constant name everywhere, which
again, defeats the purpose of using a constant instead of a literal.
So I agree with you completely. The name should be something like
gCUSTOMER_TYPE_TEACHER Or if they feel that's too much typing (I
personally don't see how it matters whether you're using SEU or anything
else, you still have to type the same keys on the keyboard) then you
might make an abbreviation for gCSTTY_TEACHER, but the important part is
that it isn't simply echoing the value inside the variable.
It's very much like a comment. It's purpose is to clarify the code, not
just echo it.
Also, I would NOT prefix these with 'g' for global. Since they are in a
copy book, they could potentially be copied in at the local-level
(internal to a subprocedure) or at the global level. What good does it
do to identify them as "global", anyway? They're constants, after all.
No chance of changing them and affecting another routine...
On 4/24/2012 7:43 AM, Dave wrote:
I would write this way, using a globally defined constant :
IF wCstTy = gCUSTOMER_TYPE_TEACHER ;
My wish was granted, and a copybook has been created. But now, I can’t use
the constant in my example above. I now have to write :
IF wCstTy = gCSTTY_TEA ;