CamelCase versus wide_names (Prothon)

François Pinard pinard at iro.umontreal.ca
Thu Apr 15 17:32:30 EDT 2004


[Mark Hahn]

> 1) CamelCase is more elegant, modern, more readable, and more efficient in
> character usage.

> 2) Wide_names is cleaner, more readable, compatible with C, which is the
> standard module language for Python and Prothon.  Wide_names is also the
> Python standard.

Both cannot be "more readable" simultaneously! :-)

For Python, I think legibility should be the premium concern.  I wish
Prothon shares that priority.

Efficiency on character usage may not be that much: there was once an
habit of removing all vowels, and a few consonants at random, from
variable names, to spare typing; this resulted in poor legibility and
harder maintenance.  Compatibility with C should not be a concern
either.  Whatever a capital or an underscore causes the highest strain
on the typist may not be more important than legibility either: editors
rather than languages should address editing difficulties.

The problem here is that legibility is not defined the same way by all
people.  People develop habits, find more legible what they saw a lot,
and are likely to fight to protect what they learn to find good.  (This
is like smoking: children gag the first time they try it, then they get
used to it, but the habit does not make smoking a good thing, even if
they much like it.)  My own opinion is that identifiers are better clean
than elegant, because legibility lies on the clean side.  This is why I
prefer wide_names.  But maybe wide_names are my drug and I'm wrong.  I
do know that others prefer CamelCase.  I do not fully understand their
preference, they do not really understand mine! :-)

Given full power and choice, what I would prefer is that identifiers be
allowed to contain spaces -- would they have to be unbreakable spaces.
That would be the most legible avenue, especially given that my editors
and enscripters would then bold or colour Python/Prothon keywords, making
it clear the extent of each identifier.  Take this very message, save
it in two files, then edit the first copy to replace all spaces within
a sentence with underlines, and edit the second copy to replace all
spaces within a sentence with the empty string, but capitalising the
next character.  My guess, which some might challenge, is that there
will almost be a concensus that the first copy is easier to decipher.

Legibility should be the overwhelming concern.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard




More information about the Python-list mailing list