CamelCase versus wide_names (Prothon)

[Mark Hahn]

We have agreed in Prothon that unlike Python we are going to be 100%
consistant in our var and method naming. We will not have run-together
words like iteritems, we are going to always have seperated words like
has_key.

Now we are in the midst of a discussion of camelCase versus wide_names. So
far our arguments are:

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.

Of course in the Python world you alread have wide_names as your standard,
but could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

Thanks in advance...

 

[Peter Hansen]

We have agreed in Prothon that unlike Python we are going to be 100%
consistant in our var and method naming. We will not have run-together
words like iteritems, we are going to always have seperated words like
has_key.

Now we are in the midst of a discussion of camelCase versus wide_names. So
far our arguments are:

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.

Of course in the Python world you alread have wide_names as your standard,
but could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

camelCase, provided acronyms (if any) are treated as words and
capitalized appropriate. For example, updateGui() is preferred
to updateGUI() (or update_GUI or update_gui). IBM did it right
with the OS/2 API (at some point, finally).

Of course, someone once said that a foolish consistency is the
hobgoblin of little minds...

-Peter

 

[Hugh Macdonald]

pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for
which you'd prefer?

I've not really been following Prothon in general, but I'm happy to give my opinion on this....

I think most people use whatever they 'grew up with' (in the programming sense...). I started programming in UnrealScript (Unreal/UnrealTournament coding) and I still use the naming schemes that they used in their code...

camelCaseAllTheWay (unless I'm extending someone else's code and they've used wide_names)

I also use kinda-hungarian notation, in that all of my boolean (or pseudo-boolean) variables are:

bVariable

(by pseudo-boolean I mean an int acting as a boolean, for example)

When I'm reading code, this makes sense, as I read:

if bTurnedOn:

as

If be turned on:

Anyway, I think the answer that you're looking for from me is camelCaps all the way....

 

[OKB (not okblacke)]

Of course in the Python world you alread have wide_names as your
standard, but could you for the moment pretend you were picking
your standard from scratch (as we are doing in the Prothon world)
and give your vote for which you'd prefer?

camelCase, hands down. Underscores are much too difficult to type,
and in my opinion should be avoided except when you WANT a hard-to-type
identifier (as with private variables, etc.).

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Kevin Altis]

If you're using PEP 8 terminology then CamelCase is different than
mixedCase. CamelCase is often used for class names and mixedCase for
everything else.

"""
- CapitalizedWords (or CapWords, or CamelCase -- so named because
of the bumpy look of its letters[4]). This is also sometimes known as
StudlyCaps.

- mixedCase (differs from CapitalizedWords by initial lowercase
character!)
"""

ka

 

[Richie Hindle]

[Mark]

could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

My preference is for camel case, with initial caps only for class names:

--------------------------------------------

moduleVariable = 3

def myFunction(formalParameter):
localVariable = None

class MyClass:
def methodName(self, formalParameter):
localVariable = None
self.myAttribute = None

--------------------------------------------

I don't have any scientific backing for that - just "it looks right to me".

That said, 99% of the standard library disagrees with me and uses wide_names
(at least for method names) which is a pretty powerful argument for adopting
that as your standard:

$ egrep "( |\t)+def " *.py | wc
3353 14222 154294
$ egrep "( |\t)+def [a-z0-9]*[A-Z][a-z0-9]*\(" *.py | wc
39 148 1645

....OK, 98.837%

Class names are mostly standardised on CamelCase - hardly any have
underscores:

$ egrep "^class +[^(_]+_[^(]*\(" *.py | wc
11 45 583

 

[Andrei]

Mark Hahn wrote on Thursday 15 April 2004 17:17:

We have agreed in Prothon that unlike Python we are going to be 100%
consistant in our var and method naming. We will not have run-together
words like iteritems, we are going to always have seperated words like
has_key.

I don't like underscores in variable names for the same reason as
Brendan/OKB: they're hard to type and they slow me down because: a) it's
one extra keypress compared to MixedCase (or CamelCase - depending on who
you ask) and b) even at same word length, it takes longer for me to type
the underscore than any alphanumeric character.

Personally I also find MixedCase easier to read than under_scores
(especially in code and especially when more than two words are
concatenated, e.g. AskUserPermission vs. ask_user_permission - the first is
immediateyl obvious as being one word, the second might fool me at first
(quick) glance into thinking it's three words). I'm not sure if this
universally true or just a matter of what I'm used to.

--
Yours,

Andrei

=====
Real contact info (decode with rot13):
(e-mail address removed). Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V ernq
gur yvfg, fb gurer'f ab arrq gb PP.

 

[Roy Smith]

Here's my entirely non-scientific two cents on this.

I stated out programming on teletypes and card punches which only had a
single case, so I got used to underscores. When bumpyCase started
showing up 10 or 15 years ago, I thought it was froofy and ugly and
hated it. Gradually, I've come around and now find mixed upper/lower
very natural (including the initial cap for class names) and despise
underscores. If an old goat like me can change, I figure everybody else
can too.

It's entirely unclear how any of the above should influence your
decisions on language design

 

[Mark Hahn]

It's entirely unclear how any of the above should influence your
decisions on language design

It may not technically be part of the language design, but aesthic issues
like this need to be decided up front or they will be decided randomly.
Users on the Prothon mailing list were asking me (I'm the BDFL there) to
change from wide_names to camelCase and I wasn't letting them, because
Python used wide_names and I have a rule about following Python unless there
is a good reason to change.

Then I came here and asked and to my surprise I'm finding out that 100% of
python users want camelCase. This kind of blows away my argument against
it. So camelCase it will be.

Now I'll go through all the Python method and var names and convert them all
to camelCase for Prothon. It shouldn't be a problem for users since the
conversion is mechanical.

 

[Michael Geary]

If you're using PEP 8 terminology then CamelCase is different
than mixedCase. CamelCase is often used for class names and
mixedCase for everything else.

Just to add to the confusing terminology, in some circles mixed case with an
initial lowercase letter is called camelCase, while mixed case with initial
uppercase is called PascalCase.

http://c2.com/cgi/wiki?CamelCase
http://c2.com/cgi/wiki?PascalCase

In any case ;-) Mark is referring to both forms, WithInitialCapital and
withoutInitialCapital.

The initial capital letter actually has significance in Prothon (I
think--unless that has changed). So the question is whether to use
NamesLikeThis and namesLikeThis, or Names_like_this and names_like_this.

-Mike (instigator of the discussion and major fan of [Mm]ixedCaseNames,
whatever they are called)

 

[A.M. Kuchling]

Of course in the Python world you alread have wide_names as your standard,
but could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

Wide_names: for a while I wrote code using mixedCase, but subsequently
switched back; the resulting method/function names are easier to read
and to talk about.

--amk

 

[JCM]

Then I came here and asked and to my surprise I'm finding out that 100% of
python users want camelCase. This kind of blows away my argument against
it. So camelCase it will be.

I prefer names_with_underscores.

 

[Jarek Zgoda]

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

I use CamelCase in my ObjectPascal (Delphi, FP) code. Looks really good,
but it's Pascal.

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.

I don't like underscores. I know, it's my problem.

Of course in the Python world you alread have wide_names as your standard,
but could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

mixedCase, like in Java (sorry). This convention makes clean distinction
between objects and classes. I like it. Am I crazy? Yes, I am.

 

[Joe Mason]

Of course in the Python world you alread have wide_names as your standard,
but could you for the moment pretend you were picking your standard from
scratch (as we are doing in the Prothon world) and give your vote for which
you'd prefer?

Wasn't one of the Prothon design goals "when in doubt, follow Python"?

Joe

 

[Wilk]

We have agreed in Prothon that unlike Python we are going to be 100%
consistant in our var and method naming. We will not have run-together
words like iteritems, we are going to always have seperated words like
has_key.

Now we are in the midst of a discussion of camelCase versus wide_names. So
far our arguments are:

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.

Before, i used CamelCase, but now i use only wide_name because i find
that capitals letters are a pain for the finger and the wrist. For
example when you whant to write Q (on querty or azerty keyboard), with
one hand you must make a gymnastic, or you will need two hands.

The best is to try the two very quickly... I've replaced thousand of
lines after it ! But maybe it depends how we use the keyboard...

Of course in the Python world you alread have wide_names as your standard,

Not everytime and i regret...

 

[Jarek Zgoda]

Before, i used CamelCase, but now i use only wide_name because i find
that capitals letters are a pain for the finger and the wrist. For
example when you whant to write Q (on querty or azerty keyboard), with
one hand you must make a gymnastic, or you will need two hands.

Underscore is such same pain. I cann't see any advantage.

 

[Jan Dries]

Then I came here and asked and to my surprise I'm finding out that 100% of
python users want camelCase. This kind of blows away my argument against
it. So camelCase it will be.

In all fairness, you are finding out that 6 of the 8 first people to
respond to your post prefer CamelCase. The other two didn't voice a
clear opinion in either direction. While I'm sure that might be
indicative of some trend, it certainly does not mean 100% of Python
users want camelCase.

I for one go with AM Kuchling, and prefer wide_names.

When I started programming, I was using C (this was back in the 80's and
early 90's) and I used to code all in wide_names. I was quite happy with
it. Then I started writing C++ on Windows, and I gradually started using
CamelCase and lpszqvwxHungarianNotation, primarily because MFC was using
it. When Java came out, I followed its camelCase practice as well.
But it wasn't until I moved to Python in 2000 that I realised how much I
really prefer wide_names. Contrary to what others have written here, I
find wide_names much more readable than camelCase.

In practice though, I tend to go for whatever convention is customary in
the environment I work in. And I have long given up the illusion you can
be 100% consistent in these matters. That's why I rarely get involved in
discussions like these. But when someone claims 100% of Python users
want camelCase, I cannot but speak up.

Regards,
Jan

 

[Wilk]

Underscore is such same pain. I cann't see any advantage.

On azerty keyboard _ is under 8 and does'nt need to press shift... I
did'nt remember that it's diffent on qwerty.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[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.

 

[Roy Smith]

But when someone claims 100% of Python users
want camelCase, I cannot but speak up.

I hope this doesn't turn into a flame war, but I agree with Jan. One of
my pet peeves is expressing a minority opinion ("I want X") and then
hearing my opinion dismissed with a statement like "Everybody wants Y".
I'm willing to be outvoted, but I sure won't stand for being ignored.

I happen to be one of the people who expressed the majority opinion,
i.e. in favor of DromiDaryOrthoGraphy, but it's still unfair to say that
100% of Python users agree with me.