Re: Long Constant Names

Paul,

I agree with you for constants that are defined in a procedure. That's the best 
solution because context is clear and names can be short and readable. Whenever 
I can, I do that.

In the present case, I was referring to constants used by 10+ programs. To 
comply with the DRY guideline (Don't Repeat Yourself), these constants are 
defined in their own /copy book, as you suggest. I'm not worried about context 
where the
constant is declared. I'm worried about where the constant is used. If the 
constant name had to be qualified with the /copy book name, there would be no 
problem. But if you have a Branch /copy book and an Account /copy book both 
defining an
'Open' constant, how can a program importing both /copy books checks if both a 
branch and an account are open?

To sum up, I agree with you if the constant is defined close to where it is 
used, context is obvious and doesn't have to be stated. But other forces 
sometimes dissuade me from defining the constant close to where it is used. 
When that
happens, context becomes a crucial information.

Using a 'm' prefix or suffix for messages is not a bad solution. As a matter of 
fact, using abbreviations is not a bad thing, as long as they are used 
consistently across all the programs of the project. That requires that there 
be an
official project abbreviation lexicon, and that it doesn't become so big and 
unwieldy that even old timers can't remember most of it.

Yet, I feel abbreviations are just a way to reduce the problem, not to cure it 
once and for all.

Regards.

--
Antoine CONTAL



Antoine,

Personally I'm not sure why you need context in the variable name.  Context
should be provided by where the constant is defined.  Don't define the
constant in a global list but define it in the procedure where it is used.
If that requires multiple definitions of the constant in multiple procedures
then accept that or put
the constant definition in a /copy book.  If it's in a /copy book then the
name of the copied member would also provide the context (/Copy AppState).
wwUpdateFailMsg won't work as a variable name if it's defined 'close' to
where it is used?

I'd also try to take Msg out of the constant name.  That's really a 'type'
suffix you've added on to the name.  Lowercase m might suffice as either a
prefix (polish) or a suffix.  wwmUpdateFailure won't work as a variable
name?

Paul

--
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333



Les informations contenues dans ce message sont confidentielles et peuvent 
constituer des informations privilegiees. Si vous n etes pas le destinataire de 
ce message, il vous est interdit de le copier, de le faire suivre, de le 
divulguer ou d en utiliser tout ou partie. Si vous avez recu ce message par 
erreur, merci de le supprimer de votre systeme, ainsi que toutes ses copies, et 
d en avertir immediatement l expediteur par message de retour.
Il est impossible de garantir que les communications par messagerie 
electronique arrivent en temps utile, sont securisees ou denuees de toute 
erreur ou virus. En consequence, l expediteur n accepte aucune responsabilite 
du fait des erreurs ou omissions qui pourraient en resulter.
--- ----------------------------------------------------- ---
The information contained in this e-mail is confidential. It may also be 
legally privileged. If you are not the addressee you may not copy, forward, 
disclose or use any part of it. If you have received this message in error, 
please delete it and all copies from your system and notify the sender 
immediately by return e-mail.
E-mail communications cannot be guaranteed to be timely secure, error or 
virus-free. The sender does not accept liability for any errors or omissions 
which arise as a result.
$!2$!