Path: utzoo!mnetor!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Re: Readable names
Message-ID: <2883@enea.se>
Date: 20 Mar 88 15:29:13 GMT
References: <2857@enea.se> <25668@cca.CCA.COM>
Reply-To: sommar@enea.UUCP(Erland Sommarskog)
Followup-To: comp.lang.misc
Organization: ENEA DATA AB, Sweden
Lines: 32

Richard Harter (g-rh@CCA.CCA.COM.UUCP) writes:
>	I agree that NumOfAcc is worse than NumberOfAccidents.  There
>are human factor studies that back this up.  Ordinarily.  
> ...
>	However that was not what I meant -- I meant na or nac instead
>of NumberOfAccidents, coupled, of course, with clear documentation of
>what na, et. al. mean.  I will grant that na is not as menmonic as
>NumberOfAccidents.  ... The
>name is a symbol; I only need to find out what it means once; I don't
>need to be told what it means everytime that I see it.  The long name
>is, in effect, a redundancy that increase the noise level in a program.

I must admit that I detest such naming conventions. Yes, if "na" is
very frequent and appears everywhere, and is not accompanioned by "lp", 
"oi" etc, well OK. But if I have to look up the definition each time I 
see it, it's a big loss. This is exactly why dislike things like Unix
and nroff with their short, seldom-mnemonic names. I find it very tire-
some to have look up the same thing more than once. 
  You write that this is your personal preference. I don't agree here.
Most likely someone else will have to work with your code some day.
I'm quite sure it will take him a longer time to understand your "na" 
than NumberOfAccidents.

I can agree with you so far that using abbreviations for frequently
occuring entities. But just as too many long names increases the
noise level, too many abbreviations does as well. 

-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Si tu crois l'amour tabou...
                            Regarde bien, les yeux d'un fou!!!" -- Ange