Noob - Getting Started Infinte Loop?

[Richard A. O'Keefe]

Bengt Kleberg <bengt.kleberg@REDACTED> wrote:
	> It is more than my personal opinion since 100% of the people i have 
	> asked say that NamesThatLookLikeThis are harder, or about as easy after 
	> learning how to do it, to read than Names_that_look_like_this.
	> Nobody has ever claimed that they are easier to read.
	
Garry Hodgson <garry@REDACTED> retorted:
	you must have asked the wrong people.
	
IfThereReallyArePeopleWhoFindThisKindOfTextEasierToRead
Then_Text_That_Looks_Like_This,
then we have empirical evidence for the existence of more than
one human species.  (:-)

The Ada Quality and Style Guidelines include the following section:

    3.1.1 Use of Underscores

    Guideline

    - Use underscores to separate words in a compound name.

    Example

	Miles_Per_Hour
	Entry_Value

    Rationale

	When an identifier consists of more than one word, it is much
	easier to read if the words are separated by underscores.
	Indeed, there is precedent in English in which compound words
	are separated by a hyphen or a space.  In addition to promoting
	readability of the code, if underscores are used in names, a
	code formatter has more control over altering capitalization.
	See Guideline 3.1.3.

There's a reference later on to a book
    Empirical Studies of Programmers,
    edited by E. Soloway and S. Iyengar.
    Norwood, NJ: Ablex Publishing Corp
    1986

I have never seen that.  Anyone got a copy?

There's an interesting paper
    What's in a Name? A Study of Identifiers
 by Dawn Lawrie, Christopher Morrell, Henry Feild, & David Binkley
but that explores what the words should be like, not whether there
should be underscores between them.


Attila Feher pointed out that the baStudlyCaps convention
doesn't work for identifiers like
    SMTPTCPIPConnection
which would work just fine as
    SMTP_TCP_IP_Connection

Hmm, you don't happen to know a language that's often used for programming
networks, in which you often have to mention heavily acronymed stuff, do you?

Bertrand Meyer has a chapter on style,
    http://archive.eiffel.com/doc/manuals/language/style/style.pdf

One paragraph of that says

    For composite names, it is better to avoid the style, popularized
    by Smalltalk and also used in such libraries as the X Window System,
    of joining several words together and starting the internal ones with
    an upper-case letter, as in "yearlyPremium".  Instead, separate
    components with underscores, as in "yearly_premium".  The use of
    internal upper-case letters is ugly; it conflicts with the conventions
    of ordinary language; and it leads to cryptic names, hence to possible
    errors (compare "aLongAndRatherUnreadableIdentifier" with
    an_even_longer_but_perfectly_clear_choice_of_name).

In Smalltalk's defence, I must point out that it was originally developed
on machines that didn't *have* an underscore character on their keyboards
or in their character set, and that the ANSI Smalltalk standard *does*
include underscores, at least some modern Smalltalkers agreeing with Meyer.
Me, I've written enough Smalltalk to be used to baStudlyCaps and to have
written more code than I care to remember in that style, and what chiefly
sticks in my mind is not how easy or hard it is to read, but how annoyingly
hard it is to get readable class names.  (Given a convention where a
programmer's classes are prefixed with their initials, and the package
is called OXUS, and I want to talk about an XML ID, RAOKOXUSXMLID is
forced on me, but it's horrible.  I desperately want RAOK_OXUS_XML_ID.
The convention does *not* allow Raok, Oxus would be wrong, the notation
is XML, not Xml, and the XML specification calls them ID, not Id, so
RaokOxusXmlId would be wrong.  (And on my screen, the "l" of Xml and
the "I" of "Id" look pretty similar, so it's surprisingly hard to see
where the dividing point is.)

If you have PERL installed on your machine, try 'man perlstyle',
where you'll find

	While short identifiers like $gotit are probably ok, use
	underscores to separate words.  It is generally easier
	to read $var_names_like_this than $VarNamesLikeThis,
	especially for non-native speakers of English. It's also
	a simple rule that works consistently with VAR_NAMES_LIKE_THIS

I've just spent nearly an hour searching for some experimental writeup
about this.  I guess it's one of those things, like "other things
being equal, it is better if the default base for integers in a program
is 10 rather than 8" (don't laugh, I've met languages where it really
was 8) that are so obvious that nobody bothers to measure them.