× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well that settles it. The fact that the famous Scott Klement agrees with me
should be enough to convince anyone.

But, I don't like the idea of putting the field name in the constant name,
like CSTTY_TEACHER, because CUSTOMER_TYPE_TEACHER could be used in any
language. It seems to me that it would be unlikely that if I were a Java
programmer that I would use gCstTy in my code for a field name.




Le 24 avril 2012 19:06, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> a écrit
:

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 ;

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.