🚀 go-pugleaf

In article <2921@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:

>Me and Richard Harter have been exchaning points of view on identifier
>names for a while.
>
>>	Oh, I see your point alright.  I find NumberOfAccidents hard
>>to read and unpleasant, whereas Number_of_Accidents is more pleasing to
>>mine eye.  
>
>Underscore of case shifts doesn't really matter to me, as long as it is 
>not "numberofaccidents". It was there my discussion started. These days 
>I prefer underscores, before I used case shifts.
>standard Pascal, that's why.

The above exchange roughly summarizes what has been a largely inconclusive
discussion, to wit: everyone diving into a large chunk of unremembered or
alien code finds it much easier to read if there are fully descriptive
names, while anyone actively writing code inevitably mimizes names for the
sake of mechanical expediency.

So what?  We are all entitled to our own views and idiosyncrasies, but we
are typically paid to produce working, understandable, flexible,
maintainable, etc. code.  If in doubt, make the computer pick up the slack.
It doesn't take much effort to adapt one of today's editors/browsers to
using a name alias table, or to make global changes to names in a compile
unit via a name substitution list.  Like everyone else, I have developed a
set of coding habits over the years, and every so often I find that my
style is at odds with local convention/standards.  When this happens, I can
either attempt to change my habits, or I can build a transformer which will
massage my (consistent) code into the required local format.  I long ago
learned that the second approach is much more successful (amazing how set
in ones ways it is possible to get!), and have seldom encountered any
problems finding a suitable engine with which to perform the transforms.

I am a short(ish) name, underscore separator, case-insensitive programmer
from habit (PL/1 origins, you know), but I have discovered that a simple
comment attached to each identifier declaration (I always explicitly declare
all identifiers) makes future understanding of code substantially easier.  I
can also use said descriptive comment to hold a longer descriptive name in
a form suitable for automatic extraction and substitution.

For those of you who are interested in the cognitive psychology aspects of
understanding case-sensitive text, a substantial amount of work has been
done in this field.  It seems that single case becomes a problem only when
the length of text becomes significant (useful word that, which I won't
explicate here :-) ), or when proportional fonts are in use.  E-mail me if
you have difficulty finding references on your own.

Totally subjective observation on the subject:  case sensitivity is
undoubtedly useful, but it sure introduces a whole lot of problems.

Ummm, don't you think we've about bashed this subject to death?

Robert_S
-- 
Robert Stanley - Cognos Incorporated: P.O. Box 9707, 3755 Riverside Drive
Compuserve: 76174,3024		      Ottawa, Ontario  K1G 3Z4, CANADA
uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts  Voice: (613)738-1440(Research)
arpa/internet: roberts%cognos.uucp@uunet.uu.net   FAX: (613)738-0002