× 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.



I've never seen much value in Hungarian notation, myself. If I want to know whether a variable is global/local or what it's data type is, I'll just go look... honestly, I rarely get confused by something like that, and if I do, looking it up isn't that difficult.

The problem I always have -- particularly in ILE programming -- is conflicts with other constants. For example, in my copybook for my service program, I define a constant named SUCCESS and FAIL. Then some other programmer writes a service program and also codes SUCCESS and FAIL... now I can't include both copy books in the same caller, because they have duplicate definitions.

It's especially a problem when expanding an existing tool. I might add new constants to my service program and release an updated version.... existing callers might work if I don't recompile them, but they might hit a conflict years later when they're next recompiled... So the initial test of the program was okay, but a minor update causes a failure later... what should've been a simple project becomes a headache.

So I tend to use a prefix that relates to the service program. Each service program in our system has a unique prefix, like say, PURCH is used for the purchase order service program. the constants (as well as prototypes, data structure templates, module names, etc) are all prefixed by PURCH.. and you have PURCH_SUCCESS and PURCH_FAIL. That way, it never conflicts, because other service programs don't start with PURCH.

To me, that's far more valuable than hungarian notation.

For locally-defined constants, the name of the constant doesn't matter so much... there's rarely a conflict, and assuming you don't use a stupid name like your gA = 'A' example, they're easy enough to understand. So we don't really have any sort of naming standard for those.

I also prefer to type my constant names in ALL_UPPER_CASE, and type my variables in MixedCase or lowercase. That way, there's a visual clue that you're working with a constant vs. a variable.


David FOXWELL wrote:
Hi people,

I'd like some comments concerning the use of constants. I've been asked to prepare a presentation to the team for a discussion on good coding practices, as the boss is getting tired of seeing this sort of thing :

* Global figurative constants
* Type relation = aunt
D gA C 'A'

myRelation = gA;

Now, I'd have written :

D gAUNT C 'A'

D gUNCLE C 'U'

myRelation = gAUNT;



Some questions :

I would normally not use a commentaire at the declaration of a constant. What do you think?

We use a prefix g to indicate a globally defined constant, and w for a locally defined one. When would you locally define a constant in a sub procedure? I think it's nice to be able to see the definitions close to the calculation specs, but isn't a constant almost always global?

What is meant by figurative constant? I thought it was one with a fixed value like *BLANK.

Thanks



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.