Re: standards for coding constants

Hi Dave,

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 ;