Noob - Getting Started Infinte Loop?
Richard A. O'Keefe
Fri Sep 1 04:54:25 CEST 2006
Bengt Kleberg <> 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 <> retorted:
you must have asked the wrong people.
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
- Use underscores to separate words in a compound name.
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
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
which would work just fine as
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,
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
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.
More information about the erlang-questions