🚀 go-pugleaf

Richard Harter (g-rh@CCA.CCA.COM.UUCP) writes:
>	I will have to disagree here.  As a caveat, I will immodestly
>say that [some of] my code has been pointed out as exemplars of clear,
>well written, well documented code.  

Well, I haven't seen it, so I can't judge. You have to post some of that
wonderful code. :-)

>	Long names take longer to read and to write.  In particular, it
>is harder to understand complicated statements.  Let me illustrate with
>a ridiculous example, in no particular language:

I beginning to feel that I am repeating myslef. But it takes longer to read
"na" than "NumberOfAccidents", unless you managed to burn a hard link
that gives an immediate understanding of "na". Else you have to waste time
to look it up or recall what it means. Same may be valid for typing: "What
abbreviation did I use?"

The use of your example (deleted for brevity) is that it shows that names
*can* be too long names sometimes, and that in certain circumstances 
short names are preferable. But we have already agreed on that, haven't we? 

>Another point is that the sort of code that I write and
>prefer to maintain is written in small modules -- short names are much
>more supportable if their scope is small.

Yes, short names are more acceptable in a small scope. But even if your
modules are small, you have a lot of global names: procedures, types,
constants, enumeration values and field elements in records. You use
your short names for these too?

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