Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > CamelCase versus wide_names (Prothon)

Reply
Thread Tools

CamelCase versus wide_names (Prothon)

 
 
A.M. Kuchling
Guest
Posts: n/a
 
      04-15-2004
On Thu, 15 Apr 2004 08:17:08 -0700,
Mark Hahn <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
 
 
 
JCM
Guest
Posts: n/a
 
      04-15-2004
Mark Hahn <(E-Mail Removed)> wrote:
....
> 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.
 
Reply With Quote
 
 
 
 
Jarek Zgoda
Guest
Posts: n/a
 
      04-15-2004
Mark Hahn <(E-Mail Removed)> pisze:

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

--
Jarek Zgoda
http://jpa.berlios.de/
 
Reply With Quote
 
Joe Mason
Guest
Posts: n/a
 
      04-15-2004
In article <UHxfc.9323$dZ1.3740@fed1read04>, Mark Hahn wrote:
> 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
 
Reply With Quote
 
Wilk
Guest
Posts: n/a
 
      04-15-2004
"Mark Hahn" <(E-Mail Removed)> writes:

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

--
Wilk - http://flibuste.net
 
Reply With Quote
 
Jarek Zgoda
Guest
Posts: n/a
 
      04-15-2004
Wilk <(E-Mail Removed)> pisze:

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


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

--
Jarek Zgoda
http://jpa.berlios.de/
 
Reply With Quote
 
Jan Dries
Guest
Posts: n/a
 
      04-15-2004
Mark Hahn wrote:
>
> 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





 
Reply With Quote
 
Wilk
Guest
Posts: n/a
 
      04-15-2004
Jarek Zgoda <(E-Mail Removed)> writes:

> Wilk <(E-Mail Removed)> pisze:
>
>>> 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.

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

--
Wilk - http://flibuste.net
 
Reply With Quote
 
=?iso-8859-1?Q?Fran=E7ois?= Pinard
Guest
Posts: n/a
 
      04-15-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

 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      04-15-2004
Jan Dries <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Mozilla versus IE versus Opera versus Safari Peter Potamus the Purple Hippo Firefox 0 05-08-2008 12:56 PM
generic programming: (in?)compatibility of CamelCase and snake_case Jeff Schwab C++ 8 03-24-2008 11:35 AM
equal? versus eql? versus == versus === verus <=> Paul Butcher Ruby 12 11-28-2007 06:06 AM
Appropriate use of camelCase Gavin Kistner Ruby 3 02-24-2004 01:27 AM
entering the lists against CamelCase John Benson Python 2 12-08-2003 12:06 AM



Advertisments