CamelCase versus wide_names (Prothon)

[Roy Smith]

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.

That's an interesting point. Most computer languages are written in
ASCII. Typographic embelishments(*) like font, size, color, and so on
are all ignored. It's only relatively recently that case has become
significant.

By contrast, the languages of math (maths to you silly Europeans),
science, and engineering are full of wonderful typography. Different
fonts, character sets, diacritical marks, character placement, and
special symbols are all meaningful. For the most part, we struggle
along with things like

$ sum from x = 0 to inf [ pi sup x * j hat * omega dot ] $

when what we'd write with pen and paper looks nothing like that.
Someday, when we finally break out of the 80-column, fixed width,
monochrome, monofont, monosize, 7-bit world, our arguments about
wide_name vs. bumpyCase will seem just as pre-historic as the $$
gibberish above.

(*) Granted, what I call an "embellishement", many people would call
"the ability to use all the letters in my native alphabet".

 

[Mark Hahn]

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.

Yes, I was definitely guilty of over-generalization. I was just so
surprised that 100% of the first 6 who gave an opinion picked camelCase that
I got carried away. Small sample sets like the first six can be deceptive,
but the odds of wide_names winning after this early response are near zero.
(Unless there is some correlation with camelCase-loving and quick-responding

 

[Mark Hahn]

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

Yes, and that was why I was voting for wide_names. Buit the logic was to
make conversion from Python to Prothon easy and to make ex-Pythoners (like
myself) happy. That logic falls apart if it is easy to convert names and
Pythoners want camelCase. After posting this question and seeing that the
majority want camelCase, I switched my vote (and have already switched
Prothon's var names; it only took 10 minutes to switch).

 

[Mark Hahn]

Both cannot be "more readable" simultaneously!

I was wondering if anyone would catch that You win the prize!

I was giving each argument from the perspective of the one who wants that
choice.

P.S. Has anyone noticed that I have finally taught myself how to not
top-post? I have been practicing the last few weeks on the Prothon list. I
has NOT been easy to un-teach 30 years of email posting method. I hope the
people that black-holed me can forgive me now and let me back in.

 

[JCM]

(Unless there is some correlation with camelCase-loving and
quick-responding

Yes, and in addition to being overzealous, those who prefer camelCase
are stubborn, sloppy coders, and have poor personal hygiene.

 

[Paramjit Oberoi]

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.

wide_names please. I have tried both and this is what I think:

* wide_names is clearer & easier to read.
- particularly with one and two letter words
- ideally I would like to be able to use hyphens
like-this, but that unfortunately clashes with
subtraction (this is the only positive thing I
remember about COBOL: variables with hyphens)

* wide_names is easier to type.
- camelCase requires the set [a-zA-Z], wide_names
only requires [a-z_]. *MY* fingers find it easier
to get used to one shift-key combination rather
than 26. I propose that the underscore key be added
to all keyboards to make things even easier (I should
remap my windows key...).

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

* I am of the opinion that identifiers/filenames/reserved words
should be case insensitive. Or alternatively, case should be
enforced but no two should be allowed to differ only in their
case. Pascal got this right...

-param

 

[Heather Coppersmith]

Given full power and choice, what I would prefer is that
identifiers be allowed to contain spaces -- would they have to
be unbreakable spaces ...

Underscores are the next best thing, depending on your font. I
remember the Good Old Days of ASCII terminals, when underscores
were *below* the baseline and not on it (especially effective on
those old upper-case-only ADM 3's...).

I also like Lisp's (mostly) whitespace delimited identifiers, not
so much for char< and remove-extra-['s, but for big-enough-p and
parse-integer, not to mention *global-variable* and :keyword.

Back on topic: I find mixedCase and CamelCase tolerable for short
identifiers (e.g., biggestInt and LoggingMixin), but intolerable
for longer identifiers (e.g., mostRecentMonthWithActivity).

Regards,
Heather

 

[Erik Max Francis]

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?

I'm surprised you're creating your own language and don't have enough
internal stylistic sense to make this choice yourself.

 

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

[Mark Hahn]

P.S. Has anyone noticed that I have finally taught myself how to not
top-post?

Even more, to quote parsimoniously. Congratulations!

 

[Ben Finney]

[Mark Hahn]

P.S. Has anyone noticed that I have finally taught myself how to not
top-post?

Even more, to quote parsimoniously. Congratulations!

Seconded. Thanks, Mark! It's not often I get to reduce my kill file
because the person's posting style improved.

Note that this will only encourage us to continue educating others

 

[Mark Hahn]

I'm surprised you're creating your own language and don't have enough
internal stylistic sense to make this choice yourself.

You must have some pre-conceived image of what kind of person is required to
create a language. I'd like to know more about this person.

I'm just a geek with a big ego who happens to love to create powerful simple
things. My stylistic sense is centered around making an interpreter that
runs on a simpler principle than other languages but is more flexible and
more powerful. I could care less about the appearance of variables or even
the syntax of the language, as long as it works well with my engine.

If I could I'd run pure Python, totally unchanged, on top of my interpreter,
but Python is not compatible with my simple engine.

If you visit the Prothon mailing lists you'll see that I'm letting everyone
else choose the language pretty much, except that I'm constantly trying to
make it simpler. They even had to argue to get me to use bound methods. I
had the crazy idea that they weren't needed.

So to make a long story short, I guess the language is being created by the
mailing list, not me. It will look quite different than the one that I went
public with a few weeks ago when it gets frozen in July.

I do fully realize the need for a BDFL though to keep it from being
"designed by commitee". Don't tell Guido I said this, but the BDFL doesn't
really have to be a genius. He just has to keep things moving and have
enough common sense to let the good contributors win out in the arguments.

 

[Carl Banks]

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?

Ok, get ready for this one. When I'm naming classes, instances,
functions, methods, and other complex (not complex number) objects, I
tend to use wide names. When I'm naming numbers, strings, or
collections thereof, I choose camel case before wide naming.

Why?

Well, I use wide for most objects because I think it's a bit more
readable in general, being closer to what we're used to reading. (I
guess that might not be the case for Arabic people.) But, when you
are doing all kinds of math calculations with numbers, or operating on
strings, or whatnot, the underscores make it harder to read, because
it takes effort to sort out whether something's an operator or an
underscore.

In other words, I typically use wide names because they're very
readable and nice looking in ordinary code like this:

func_status = blast_furnace.ignite_furnace()

but avoid the wide names when they're uber-ugly and unreadable in
operator-laden code like this:

pitch_rate_coefficient = pitch_rate*mean_aerodynamic_chord/total_airspeed


It would not surprise me if the people who prefer wide names tend to
be applications-type programmers, whereas those who prefer camel case
naming tend to be numerical-type programmers.

 

[Carl Banks]

By contrast, the languages of math (maths to you silly Europeans),
science, and engineering are full of wonderful typography. Different
fonts, character sets, diacritical marks, character placement, and
special symbols are all meaningful. For the most part, we struggle
along with things like

$ sum from x = 0 to inf [ pi sup x * j hat * omega dot ] $

when what we'd write with pen and paper looks nothing like that.
Someday, when we finally break out of the 80-column, fixed width,
monochrome, monofont, monosize, 7-bit world, our arguments about
wide_name vs. bumpyCase will seem just as pre-historic as the $$
gibberish above.

I'm not so sure. All this markup has got to take a lot longer to type
than plain text to input. It would take a pretty slick interface just
to match the ease of typing plain text, and then the programmer would
have to spend a lot of time learning the slick interface.

Of course, I can easily imagine a bunch of Visual Basic programmers
seeing this and saying, "Wow this is the coolest invention since the
microwave," not really noticing that their productivity had gone down
(just as they didn't notice the microwave really sucks at cooking), so
maybe it has a chance.

BTW, there are some environments that let you do this now; Mathematica
is a good example. Because it takes so much longer, I never use the
marked up input.

 

[Paul Rubin]

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

IfCamelCaseWereReallyMoreReadable, We'dWriteOrdinaryEnglishLikeUsingIt.
SoThatClaimIsRidiculousAndNeedsToBeThrownOutTheWindowPostHaste.

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.

Sounds_ok_with_me. I_find_it_a_heck_of_a_lot_more_readable_than_camel_case.
I_vote_for_wide_names.

 

[Peter Hansen]

Yes, I was definitely guilty of over-generalization. I was just so
surprised that 100% of the first 6 who gave an opinion picked camelCase that
I got carried away. Small sample sets like the first six can be deceptive,
but the odds of wide_names winning after this early response are near zero.
(Unless there is some correlation with camelCase-loving and quick-responding

There will certainly be a correlation between your original message
about the "100% prefer camelCase" and the sudden influx of messages
from wide_names folks, too though. Remember Heisenberg, and also
remember first year statistics, and remember Ada, for that matter,
and don't make your decision based on a simplistic vote like this
in the newsgroup.

-Peter

 

[Joe Mason]

but avoid the wide names when they're uber-ugly and unreadable in
operator-laden code like this:

pitch_rate_coefficient = pitch_rate*mean_aerodynamic_chord/total_airspeed

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

pitch_rate_coefficient = pitch_rate * mean_aerodynamic_chord /
total_airspeed

It would not surprise me if the people who prefer wide names tend to
be applications-type programmers, whereas those who prefer camel case
naming tend to be numerical-type programmers.

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

Joe

 

[Joe Mason]

I'm not so sure. All this markup has got to take a lot longer to type
than plain text to input. It would take a pretty slick interface just
to match the ease of typing plain text, and then the programmer would
have to spend a lot of time learning the slick interface.

ISTR LyX making this really easy.

Joe

 

[Joe Mason]

IfCamelCaseWereReallyMoreReadable, We'dWriteOrdinaryEnglishLikeUsingIt.
SoThatClaimIsRidiculousAndNeedsToBeThrownOutTheWindowPostHaste.


Sounds_ok_with_me. I_find_it_a_heck_of_a_lot_more_readable_than_camel_case.
I_vote_for_wide_names.

If you actually write code with names that long, you deserver to be
forced to read them in camelCase.

Joe

 

[Dan Bishop]

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.

Is there really a standard case convention for Pascal? What's the
point of having one for a case-insensitive language?

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.

I prefer [Nn]amesLikeThis. Except for module_names.

 

[AndrewL]

I most prefer Lisp style, which uses dashes, as in

(with-open-file (do-foo-bar))

but that's not an option. Note that I don't yet find Lisp more readable
than Python. It's just that I like the dashes.

Next would be wide_names. I think it looks less elegant than camel case, but
it's more readable for me. It's what I use in my Python (and the Perl they
force me to write at work). And I don't know why I find Lisp's dash less
jarring than underscores. It just flows better for me.

A professor in a programming class told us of a study that found
wide names are easier for non-native speakers to read. I can see that.
Compare trying to make sense of these two:

genusIrritabileVatumDel versus genus_irritabile_vatum_del, especially
if you're getting pages of it.

The ease of typing is much less of an issue for me than readability.
I have a macro in jEdit that inserts an underscore, and it's mapped
to alt-spacebar. Plus I use auto-complete. So go for (what I personally
consider) readability.

Andrew Langman