CamelCase versus wide_names (Prothon)

[Dan Bishop]

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.

ButKeepInMindThatManyIdentifierNamesHaveOnlyOneWord
(InWhichCaseTheWordSeparationStyleDoesntMatter),
AndMostOrOnlyTwoOrThreeWords, SoCodeWontBeAsHardToReadAsThis.

Out of curiosity, do most of us prefer CamelCaps for class names, regardless
of our opinions on variables, functions, methods, etc.?

I do.

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.

I'd prefer it if built-in types were uppercase too, so I wouldn't have
to remember not to use "list" and "file" as variable names.
Unforunately, that would break a lot of code.

 

[Mark Hahn]

I'd prefer it if built-in types were uppercase too, so I wouldn't have
to remember not to use "list" and "file" as variable names.
Unforunately, that would break a lot of code.

Then switch to Prothon That's the beauty of Prothon, getting to fix the
mistakes.

(I swore I'd never do that, but I just couldn't resist putting in a blatant
ad. I won't do it again. Please resume your normally scheduled
programming...).

 

[Jimmie Houchin]

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

Age has little to do with this. It probably has more to do with the environment
in which the person learned programming or does their programming.

mixedCase is minimally as old as Smalltalk 76. mixedCase it "the" way you define
names in Smalltalk. So there is a minimum of 28+ years of mixedCase programming.
Some of the oldest programmers I know of are Smalltalkers. I do not even claim
that Smalltalk originated mixedCase

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.

Smalltalk was developed by and for native English speakers. It was aimed at
being syntactically suitable for children. Squeak is being used to teach
elementary school children across the world. http://www.squeak.org

Squeak is an open source Smalltalk 80 implementation which has progressed over
the years.

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.

Smalltalk also is a big fan of descriptive names.

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*

Most of your arguments show your preference which is fine. But I disagree that
they demonstrate for your preference. Smalltalker's experience disagrees, which
too is fine. Both are opinions.

Both sides can argue for nativeEnglish, descriptive_names, etc.
Plenty of experience on both sides regarding the above. Thus, it reduces it
primarily to personal preferences and opinions.

Smalltalk itself is a testimony it isn't just young programmers who prefer
mixedCase. I am not a 65 year old programmer but I do post a significant and
historical counter example. (Nor am I a kid.)

As I am a Smalltalk (Squeak) fan I tend to prefer mixedCase. But I would not
(do_not) have any problem with wide_names.

So far outside of preference, the biggest argument I've seen in this discussion
regarding wide_names is OS handling of file_names or modules. Smalltalk has the
distinct advantage of living in its own world (image). As such its development
of Classes and Objects live inside its own image and not on the file system.

Python on the other hand is file based and does have to deal more with OS
limitations and file_names. Whether or not that is truly much of an issue, I can
not say.

Nevertheless, I'll defer to the language designers and implementors.

Jimmie Houchin

 

[Lothar Scholz]

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?

After writing a few hundert thousands lines of code in Eiffel and a
few ten thousands lines in Java i must say that lowercase wide_names
are much much better to read. Someone else already mentioned this
problem:

smtp_message <-> SMTPMessage <-> SmtpMessage

 

[William Park]

After writing a few hundert thousands lines of code in Eiffel and a
few ten thousands lines in Java i must say that lowercase wide_names
are much much better to read. Someone else already mentioned this
problem:

smtp_message <-> SMTPMessage <-> SmtpMessage

Agreed. 2nd example illustrates the main problem, where the part of
word is all uppercase. Likewise, 'smtpMESSAGE' is equally bad.

 

[Mark Hahn]

Someone else already mentioned this
If you consider the capital letter as just a replacement for the underbar,
then the answer is definitely smtpMessage. I don't see any problem.

 

[Max M]

"Mark Hahn" <[email protected]> wrote in message news:<UHxfc.9323$dZ1.3740@fed1read04>...

After writing a few hundert thousands lines of code in Eiffel and a
few ten thousands lines in Java i must say that lowercase wide_names
are much much better to read. Someone else already mentioned this
problem:

smtp_message <-> SMTPMessage <-> SmtpMessage

I would like to add that while I started out being enthisiastic about
camelcase I have switched to using wide names for variable and attributes.

So my code mostly looks like

class ThisIsAClass

thisIsAMethod()

this_is_a_variable

self.and_a_paramater

But lately I have noticed that i am switching to wide names for methods too.

This has not been a concious choice, just the way I have come to like
it. So I guess that my favourite is wide names.


regards Max M

 

[Gerrit]

Someone else already mentioned this

If you consider the capital letter as just a replacement for the underbar,
then the answer is definitely smtpMessage. I don't see any problem.

SMTP is an acronym. Because it's an acronym, it's most often spelled in
allcaps. A problem with capitalizing names by default, is that
capitalization loses a function it has in written language. Further, I
like to use capitalization naming for giving different cased names to
instances, Classes, VeryLongClassNames or CONSTANTS. But I don't think
the language should fiddle with capitalization itself. Moreover, I like
a case-insensitive language.

I find smtpMessage quite ugly to read. I find every name with caps in
the middle but no caps at the start ugly to read - I think it's called
mixedCase. I prefer lower_case_with_underscores.

I haven't followed the Prothon capitalization naming convention in
detail. But in my opinion, a multi-word name should read as a multi word
name. Underscores serve better to do so than capitalization does.

Gerrit.

 

[Max M]

Mark Hahn wrote:

I haven't followed the Prothon capitalization naming convention in
detail. But in my opinion, a multi-word name should read as a multi word
name. Underscores serve better to do so than capitalization does.

I think you should go against the tide.

Make . a normal letter.

And make _ have the function that . has in Python, so that _ and . sort
of switches meaning.

Anybody in hteir right mind can see that, that is a good idea:

 

[Max M]

Make . a normal letter.

And make _ have the function that . has in Python, so that _ and . sort
of switches meaning.

Anybody in hteir right mind can see that, that is a good idea:

Oh I forgot to include a good example:


def install.sub.skin(self, out, skin.folder):
"""Install a subskin"""

skins.tool = get.tool.by.name(self, 'portal.skins')

for skin in skins.tool_get.skin.selections():
path = skins.tool_get.skin.path(skin)
path = map(string_strip, string_split(path,','))
if not skin.folder in path:
try:
path_insert(path_index('custom')+1, skin.folder)
except value.error:
path_append(skin.folder)
path = string_join(path, ', ')
skins.tool_add.skin.selection(skin, path)
out_write('Subskin successfully installed into %s\n' %
skin)
else:
out_write('*** Subskin was already installed into %s\n' %
skin)


It is allmost freakish how hard that is to read.

On a more serious not though, what about a special notation for variables:

_this is a variable_ = 'Some string'
`Or this is a variable` = 'Some other string'

Is that to hard to read? I guess that the backtick is. It is certainly
easier to type on my Danish keyboard.


regards Max M

 

[Peter Hansen]

After writing a few hundert thousands lines of code in Eiffel and a
few ten thousands lines in Java i must say that lowercase wide_names
are much much better to read. Someone else already mentioned this
problem:

smtp_message <-> SMTPMessage <-> SmtpMessage

What about SMTP_message? If you don't deal with that issue,
you will doubtless get wide-namers who want to write it that
way instead of smtp_message.

If, on the other hand, you have a coding standard which insists
that acronyms be lower-cased, then the supposed problem you
mention above goes away, because whether you use wide_names or
mixedCase, you are consistently (not) capitalizing acronyms.

In other words, if it's a problem, it's a problem with
wide_names as well....

-Peter

 

[Michael Geary]

def install.sub.skin(self, out, skin.folder):
"""Install a subskin"""

skins.tool = get.tool.by.name(self, 'portal.skins')

for skin in skins.tool_get.skin.selections():
path = skins.tool_get.skin.path(skin)
path = map(string_strip, string_split(path,','))
if not skin.folder in path:
try:
path_insert(path_index('custom')+1, skin.folder)
except value.error:
path_append(skin.folder)
path = string_join(path, ', ')
skins.tool_add.skin.selection(skin, path)
out_write('Subskin successfully installed into %s\n' %
skin)
else:
out_write('*** Subskin was already installed into %s\n' %
skin)


It is allmost freakish how hard that is to read.

Interesting... I think you're kidding around, but I actually like that
notation quite a bit.

The problem I have with names_with_underscores is that the underscore adds
too much separation between the words, causing visual confusion over which
word belongs to which name. This is especially true in a proportional font.
Consider one of the function calls in your code, and for a moment forget
your expectations from Python, C, and similar languages:

skins.tool_get.skin.selections()

If you view that in a proportional font, the visual grouping is vivid:
skins.tool is one unit, and get.skin.selections is a separate unit. That big
fat underscore is more than twice the width of the tiny little periods, so
that's where the visual break occurs.

Compare it with the traditional:

skins_tool.get_skin_selections():

When I read that code in my mind (again viewing it in a proportional font),
I have to make an effort to prevent myself from pronouncing it this way:
"skins" (pause) "tool get" (pause) "skin" (pause) "selections". After all,
the words "tool" and "get" have only that tiny period in between, while
there is a much larger distance between the other words. (In the font I'm
viewing this in, underscore is 2.2 times the width of period, and 2.75 times
the width of an actual space character!)

Of course, in a monospaced font, period, underscore, and space are all the
same width, and so many languages use underscore as an "alphanumeric"
character and period as a separator that it would probably be confusing to
do otherwise.

But it's interesting how a proportional font stands all of this on its head,
with underscore being so much wider than the other punctuation marks.

-Mike

 

[Christos TZOTZIOY Georgiou]

Users on the Prothon mailing list were asking me (I'm the BDFL there)

If I may add a humourous note: you're the BCPFL of Prothon (Benevolent
Council President For Life), since, in the few months that Prothon
exists, you probably have asked the opinion of your current and
potential users more times than Guido did in the whole Python's
existence... Prothon is not a dictatorship for sure

Seriously: It's good that you want to please as many as you can, and I
am sure --without checking-- that initially Guido did that too for
Python; I'm also sure that this process led him to many decisions that
he later regretted. I can guess that there are matters over which you
don't bother deciding (eg identifier case), but you'll have to be more
firm and decisive, I hope you know that...

 

[Sergei Organov]

SMTP is an acronym. Because it's an acronym, it's most often spelled in
allcaps.

Yet nobody mentioned that we don't have lower-case digits

usb201_driver <-> usb201Driver <-> usb2??Driver

 

[Peter Hansen]

Yet nobody mentioned that we don't have lower-case digits

usb201_driver <-> usb201Driver <-> usb2??Driver

usbTwoOhOneDriver ? ;-)

 

[Sergei Organov]

usbTwoOhOneDriver ? ;-)

Who would call underscored version "wide names" then?

 

[Dave Benjamin]

Yet nobody mentioned that we don't have lower-case digits

usb201_driver <-> usb201Driver <-> usb2??Driver

Hey, as long as Perl is adding French quotes to the language, why don't we
dig around in Unicode for some lower case numerals? I bet you could find
some if you looked hard enough, in between the Klingon alphabet and
Dingbats 47 perhaps... =)

 

[A. Lloyd Flanagan]

FWIW, Mark, I'm with you on this one. Standardizing variable names
isn't exactly what I'd call a "deep" design decision. What's wrong
with asking experienced programmers what works best?

Speaking of which -- camelCase, definitely. Unless you want to allow
spaces in your variable names...

 

[Mark Hahn]

you'll have to be more firm and decisive, I hope you know that...

You've chosen an interesting time to make that comment. Before Prothon I've
had zero experience moderating anything, much less the barrage of opinions
that come into the language design process.

When I first started I thought everyone's opnion mattered and that I had the
job of merging eveyone's ideas into a grand scheme that made everyone happy
<hearty laugh>. Now I am discovering that everyone has there own agenda and
that to a certain degree the more we discuss, the more people polarize
around their own agenda instead of converging on a shared solution. We have
idea's that range from pure Self, to pure Python, to pure Lisp, to pure
original Prothon.

I think I have recently found a smattering of people who really do go with
the flow and we are starting to make some real progress (knock on wood).
The good news is that ultimately I have the BDFL powers and can use them
when needed. Just having the power is what is important. It is not the
using of them that is important.

 

[Peter Hansen]

FWIW, Mark, I'm with you on this one. Standardizing variable names
isn't exactly what I'd call a "deep" design decision.

> What's wrong with asking experienced programmers what works best?

Well, threads like this, for one...