CamelCase versus wide_names (Prothon)

[Hans Nowak]

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?

That would be wide_names. CamelCase would be tolerable. In my own code, I use
a mixture: CamelCase for class names, wide_names for everything else (inspired
by older Python code). Not mixedCase, mind you; IMHO, that's an atrocity. If
you're going to use caps in names, then at least the first letter should be
capitalized. Putting the capitals somewhere in the middle but not in the front
seems very unnatural to me.

 

[Michael Geary]

IfCamelCaseWereReallyMoreReadable, We'dWriteOrdinaryEnglishLikeUsingIt.
SoThatClaimIsRidiculousAndNeedsToBeThrownOutTheWindowPostHaste.
I_find_it_a_heck_of_a_lot_more_readable_than_camel_case.
I_vote_for_wide_names.

If we were writing English sentences and for some reason were forced to
write an entire sentence as a single word in one of these two styles, then I
would be persuaded by your examples.

But, we're not writing English, and we're not writing an entire sentence as
a single word.

We are writing program code where we compose a single name out of multiple
words. That name is combined with several other names in a statement or
expression with much more punctuation than you'd use in English prose.

To me, names_with_underscores are easy to read in isolation. But when they
are combined with multiple other names_with_underscores and a lot of
punctuation, the result for me is visually confusing. I have a hard time
seeing where one name ends and another one begins. Underscore is a
punctuation mark too.

But since you're using English to make the point, let's run with it a bit.
However, instead of contrived examples that no one would ever write, we'll
use a real English paragraph with real names:

I edit my Python code with SlickEdit and ActiveState Komodo. I use an IBM
ThinkPad, largely because I like its TrackPoint pointing device. I enjoy
taking pictures with my Canon PowerShot camera, and I use a PreSonus
BlueTube preamp when I play harmonica. Today I drove by OfficeMax, and I saw
ads for the DoubleTree hotel and Lufthansa's PrivateBeds and FlyNet.

What if I wrote this instead:

I edit my Python code with Slick_edit and Active_state Komodo. I use an IBM
Think_pad, largely because I like its Track_point pointing device. I enjoy
taking pictures with my Canon Power_shot camera, and I use a Pre_sonus
Blue_tube preamp when I play harmonica. Today I drove by Office_max, and I
saw ads for the Double_tree hotel and Lufthansa's Private_beds and Fly_net.

Is that easier to read?

-Mike

 

[Paul Rubin]

I edit my Python code with Slick_edit and Active_state Komodo. I use an IBM
Think_pad, largely because I like its Track_point pointing device. I enjoy
taking pictures with my Canon Power_shot camera, and I use a Pre_sonus
Blue_tube preamp when I play harmonica. Today I drove by Office_max, and I
saw ads for the Double_tree hotel and Lufthansa's Private_beds and Fly_net.

Is that easier to read?

Except for Private_beds, those are all basically single words that some
marketroid put capital letters in the middle of. They'd be better off
written as single words, which is how must people write them outside
of advertising copy: Slickedit, Activestate, Thinkpad, Powershot.

 

[Hugh Macdonald]

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

On a qwerty keyboard, _ is SHIFT+- (to the right of 0)

 

[Leif B. Kristensen]

Hugh Macdonald rose and spake:

On a qwerty keyboard, _ is SHIFT+- (to the right of 0)

In my part of the world, _ is also Shift+-, but it's to the right of
the . (period). In OO programming in general that's a bit awkward as I
frequently type a dot where I want an underscore and vice versa. This
is an error that often can be very hard to spot. So, this may be an
argument for camelCasing, - which I actually haven't used much since my
TurboPascal days.

regards,

 

[Leif B. Kristensen]

Hugh Macdonald rose and spake:

On a qwerty keyboard, _ is SHIFT+- (to the right of 0)

In my part of the world, _ is also Shift+-, but it's to the right of
the . (period). In OO programming in general that's a bit awkward as I
frequently type a dot where I want an underscore and vice versa. This
is an error that often can be very hard to spot. So, this may be an
argument for camelCasing, - which I actually haven't used much since my
TurboPascal days.

regards,

 

[Wilk]

Hugh Macdonald rose and spake:


In my part of the world, _ is also Shift+-, but it's to the right of
the . (period). In OO programming in general that's a bit awkward as I
frequently type a dot where I want an underscore and vice versa. This
is an error that often can be very hard to spot. So, this may be an
argument for camelCasing, - which I actually haven't used much since my
TurboPascal days.

Why not - instead of _ ?

def my-function()

it doesn't need shift on azerty and qwerty isn'it ?

and we already use it in natural langage...

 

[Hugh Macdonald]

Why not - instead of _ ?

def my-function()

it doesn't need shift on azerty and qwerty isn'it ?

and we already use it in natural langage...

So what happens in the following code:

data = 23
my = 2
my-data = 56
value = 3

new-value = my-data-value

Or would it insist on:

new-value = my-data - value
or
new-value = my - data - value


I think having a character available for names that is also used elsewhere as an operator is a VeryBadThing(TM) (or should that be veryBadThing or very_bad_thing?)....

 

[Wilk]

So what happens in the following code:

data = 23
my = 2
my-data = 56
value = 3

new-value = my-data-value

Or would it insist on:

new-value = my-data - value
or
new-value = my - data - value


I think having a character available for names that is also used elsewhere as an operator is a VeryBadThing(TM) (or should that be veryBadThing or very_bad_thing?)....

maybe it's possible to replace - by "minus" ?
I joke ! you're right, i keep wide_name

 

[Terry Reedy]

Why not - instead of _ ?

I believe some Lisps do use -. If so, they can do so because of the prefix
and space-separator syntax:

(- a-c c) is unambiguously a-c - c

Terry J. Reedy

 

[Andrew Henshaw]

François Pinard wrote:
....snip...

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.

Your comments bring to mind something that might be nice to see in an
editor: black text with automatic light gray underscores. This might
provide a less jarring alternative to the full underscore, but there would
be no confusion as to whether or not the separator was meant to be a space.

postscript: just tried it in my word processor and it's a pretty good effect

 

[Colin J. Williams]

That would be wide_names. CamelCase would be tolerable. In my own
code, I use a mixture: CamelCase for class names, wide_names for
everything else (inspired by older Python code). Not mixedCase, mind
you; IMHO, that's an atrocity. If you're going to use caps in names,
then at least the first letter should be capitalized. Putting the
capitals somewhere in the middle but not in the front seems very
unnatural to me.

My preferences are:

module names: lower case. to cope with case insensitive file systems
class names: PascalCase. this is comonly used
other names: camelCase. one has to choose something and this
avoids underscores
indent depth: 2 two is enough to give a visual break and
this reduces line wrape with multiple
indents

On the other hand as another contributor said, when amending existing
code, it make sense to try to stick with whatever was done before.

Colin W.

 

[Carl Banks]

Spaces are a much better way to fix this than camelCase.

pitch_rate_coefficient = pitch_rate * mean_aerodynamic_chord /
total_airspeed

Well, when you get into more complicated examples, with lots of
operators and parentheses, the spaces don't help much either. Also, I
like to use spaces to give a visual clue about nesting level, so I
don't used them in the most nested operations.

But if it makes you feel better, I don't actually use camel case
there, either. I just string the words together with no underscores
and all lower case. The OP had ruled that one out, though.

I'm somewhat surprised numerical-type programmers don't just use
ubershort variable names. Using _ for subscript:

P_r_c = P_r * ADC_m / A_t

(I'm not advocating this style, but seems like direct translations from
math or engineering algorithms would encourage it.)

I do advocate retaining the nomenclature of the domain you're
programming in, as long as the names are of local variables or
structure attributes. However, the OP's question was about neither
local variables nor domain-specific naming, so I didn't bother with
this possibility.

 

[Doug Tolton]

I believe some Lisps do use -. If so, they can do so because of the prefix
and space-separator syntax:

(- a-c c) is unambiguously a-c - c

Terry J. Reedy

Terry,

You are right, in fact all Lisps that I've used use a hyphen as the
convention for variable separators.

(defun my-function (this-is-a-variable another-variable)
(run-another-function this-is-a-variable another-variable))

Above is a rather verbose example of some lisp code. Lisp uses
whitespace as token delimeters which opens up some very interesting
possibilities for variable names such as *a-global-variable* and many
others. The hyphen I find is by far the easiest, most natural and
visually appealing method for concatenating words IMO (it happens to be
the method we use in english as well), it also requires the least amount
of keystrokes. However the hyphen can only be used in a postfix or a
prefix notation as it is in Lisp. With an in-fix syntax like Python I
don't know how you could un-ambiguously determine the difference between
"a minus b" and an identifier named a-b.

Given the lisp background, I started out using mixedCase and
PascalCasing as a convention many years ago. I found out over the years
that people have a hard time deciding whether or not some words should
be all in caps, or only in intial caps (someone used an example above
something to the effect about theGui or theGUI or TheGUI or even
TheGui). A lot of people who love mixed-casing tend to minimize the
problems with this when using a case-sensitive language, but it gets
irritating always having to look up the casing on function calls.

Personally I like wide_names better than mixedCase in any language that
doesn't allow me to use the hyphen for tokens. My vote is that you
stick with wide names since you are modeling Prothon on Python. If you
were modeling it on Java or C#, then I would agree with mixedCase. Of
course this is an aesthetic issue and taste varies wildly on this issue.
At my place of employment we have agreed that whoever created the
module gets to determine the format (ie, mixedCase or wide_case). As
you can imagine we have an abundance of stylistic choices.

 

[Jack Diederich]

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.

<blood curdling scream>Noooooo!</bcs>

As others have pointed out down the thread, don't just go on the first
several replies.

I'm a wide_case_fanboy, having done mixedCase and wide_names over the last
fifteen years. It all comes down to personal preference, of course. IMO
mixedCase people tend to be younger, and younger people tend to be more
zealous on newsgroups.

I'm also a native English speaker, so this_looks_like_words while
thisLooksAwkward. I can read/write both and do depending on who is paying
for the project, but I much prefer the underscores. I can also type 100+
words per minute (much faster than I can think) so I'm limited by figuring
out what I want to do and not by hitting shift-minus.

Mixed case works fine on two word variables because twoWords are as easy
to read as two_words. But it gets painful forLongerVariableNames.
I'm a big fan of descriptive names and since mixed case seems to discourage them
when N > 2 that is enough reason to dislike it.

My assertion that mixed case fanboys are young and therefore loud while
at the same time being too inexperienced to know the difference is harsh and
I'm sure a 65 year old programmer will post as a counter example. They
are called stereotypes because they work /most/ of the time, if they worked
/all/ of the time they would just call them truths. *wink*

-jackdied

 

[Peter Hansen]

I'm a wide_case_fanboy, having done mixedCase and wide_names over the last
fifteen years. It all comes down to personal preference, of course. IMO
mixedCase people tend to be younger, and younger people tend to be more
zealous on newsgroups.

Define "younger".

 

[Mark Hahn]

Mixed case works fine on two word variables because twoWords are as easy
to read as two_words. But it gets painful forLongerVariableNames.
I'm a big fan of descriptive names and since mixed case seems to discourage them
when N > 2 that is enough reason to dislike it.

Don't forget that I'm only talking about the built-in names like hasAttr,
rowCount, Etc. These are all pretty short and fairly non-descriptive. We
aren't the naming police who are going to force people to use one naming
convention for all the module code they write. I can't think of many
built-ins longer than two words, so you are pretty much agreeing with using
camelCase here.

 

[Jack Diederich]

Define "younger".

... than "me"
specifically people who know close to one language.

Generally I've been happier with each language I've ever programmed in,
and have been choosier at each junction. By the time I got out of uni it
was C++, branching out into Java and Perl and settling on Python for a few
years now. With many more (Objective C, Lisp, Haskell) used along the way
for hobby projects. You start with what you know and then get pickier
once you know more about what exists.

Strength of the belief that you have found the one true way is inversely
proportional to the number of things you have tried. Java and VB folks
are more likely to have an N of one and a belief approaching unity. They are
also more likely to be mixedCase people. That is my opinion.

Variable naming isn't high on my list of religious wars[*], I mentioned in
my other post I do write both mixed and wide words depending on the codebase.

But when I get to pick, I pick wide words.

-jackdied

[*] for vi lovers, I've been know to order light beer 'by accident' when
buying a round. Not really, but that is how tepid I am about my emacs
preference.

 

[Michael Geary]

Strength of the belief that you have found the one true way is
inversely proportional to the number of things you have tried.
Java and VB folks are more likely to have an N of one and a
belief approaching unity. They are also more likely to be
mixedCase people. That is my opinion.

I'll volunteer to be the exception that proves the rule.

I'm 52, have been programming since 1968, and have coded in at least 30
different languages, using all of the naming conventions that have been
discussed here along with a few more.

I spent many years coding using names with underscores, but now I'm a big
fan of mixed case names and use them in all of my code. In fact, you can
blame me for talking Mark into changing Prothon to use mixed case names.

So, it ain't just the young'uns with limited experience.

-Mike

 

[Dave Benjamin]

* the real problem is the absence of a character for
indicating non-breaking spaces---that's why we have
to use all these damn_WorkArounds.

That's so funny; I was just thinking the same thing myself. After all these
years, they couldn't just make it easier to press? That's the only problem
here, IMHO; I *much* prefer reading lowercase_with_underscores. I never
noticed how much until I read this thread, because I have a slight hangover
and all these capWordsAreLiterallyGivingMeAHeadache.

Out of curiosity, do most of us prefer CamelCaps for class names, regardless
of our opinions on variables, functions, methods, etc.? I almost never see
class names defined in lowercase unless they're built-in or user-defined
types meant to look like they're built-in.