The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Why do people hate underscores?

It_seems_obvious_to_me_that_using_underscores_for_spaces
isSlightlyMoreReadableThanUsingCamelCase.

OK, I used an extreme example to prove the point.

The only argument I've ever gotten is that it's harder to do because of the shift key.

First, I wonder how you do camel case without the shift key.

Then I wonder whether you think ease of typing is more important than the comprehension of the colleague who has to debug it six months from now.

Is there another reason?
Wes Groleau
Tuesday, October 14, 2008
 
 
Because underscores in method names looks stupid. And you often want to name your methods after the data that it operates on. So in Java:

getFirstName

is obvioulsy a getter on the firstName field.

And getfirst_Name doesn't make much sense. So you would at least have to camel case it anyway such as getFirst_name or getFirst_Name. Now suddenly it should be apparent that this forces us to create too many rules for capitalization of method names.

Therefore, getFirstName() and firstName are excellent choices and very easy to remember the rules for.
dood mcdoogle
Tuesday, October 14, 2008
 
 
I'm not taking sides, but using the fact that a variable name uses camelcase as a reason for method names to use it is a bit pointless!

how about get_first_name() returns first_name ??
Martin
Tuesday, October 14, 2008
 
 
I think it depends on the language, and the standards adapted for it.

For example, when I write Java or JavaScript I use camelCase, because that's what the documentation uses.  When I write C#, I use PascalCase for methods, and camelCase for variables.  When I use (ugh) VBScript, I use sHungarianPascalCase.  When I use Ruby, i_use_underscores because the Ruby community uses them.

Personally, I find camel case to be easier to read than underscores, because my eyes see the underscore and I have to register it for a nanosecond.  But I can, and do, use both.
WayneM. Send private email
Tuesday, October 14, 2008
 
 
OP: you use a strange definition of 'prove'. In your example it is 'obvious' to me that camel case is more readable. We can't both be right. Can we?
Larry Lard
Tuesday, October 14, 2008
 
 
<quote>
It_seems_obvious_to_me_that_using_underscores_for_spaces
isSlightlyMoreReadableThanUsingCamelCase.
</quote>

And here's the first hiccup in your argument. I find camel case to be much more readable than names that include underscores.
Bruce
Tuesday, October 14, 2008
 
 
Not to mention that an underscore is a separate character (makes names longer and requires an addl. keystroke).
BillAtHRST
Tuesday, October 14, 2008
 
 
+1 for Bruce
mwb
Tuesday, October 14, 2008
 
 
When in Rome, do what Romans do. If the environment style uses a convention then follow that convention. Otherwise when you use code snippets from example code you will either have to reformat it (possibly creating bugs) or have multiple styles (possibly creating bugs).

In SQL we put an underscore into almost every table and column name to avoid reserved word clashes across multiple DBMSs and future releases.

My issue against underscores is that double clicking to select a piece of text will sometimes only select the one part of it instead of what I really wanted. Each editor/browser/mail client/etc has a different interpretation of double click to select so the excess punctuation becomes unproductive.
jz Send private email
Tuesday, October 14, 2008
 
 
If you can get away without an underscore, it's better (shorter).

Some names need an underscore to differentiate different capitals.  IAmAnFTPPtr could be clearer as I_Am_An_FTP_Ptr, or even IAmAnFTP_Ptr.

The other problem with underscores is they're hard to say.  If you're discussing variables out loud in a code review, My_Var and MyVar sound a lot the same, unless you say "My-underscore-Var", which is awkward.

And the last part is you shouldn't HAVE a variable name that differs only by underscores, because that is very confusing.  If you use My_Var one place, and MyVar elsewhere, each time you write it again you have to figure out which context you're in.

Forbidding underscores thus has some value to it.  Personally, I find an occasional underscore to be quite useful.  But only an occassional one.
AllanL5
Tuesday, October 14, 2008
 
 
You can't do camel case without the shift key?!

Hello... hello... anybody home? It's called "CAPS LOCK". Like... *duh*.
brone
Tuesday, October 14, 2008
 
 
The issue is that developer stops noticing blanks. I once worked on code base where they had policy on this style of code. Here is small sample:

class source_providers_collection_class
{
...
};

source_providers_collection_class* p_source_providers_collection = new source_providers_collection_class ();

and so on.
I had headaches from looking at that style.
asmguru62 Send private email
Tuesday, October 14, 2008
 
 
"Because underscores in method names looks stupid."

Not in Ruby they don't.

def first_name
  @first_name
end
John Topley Send private email
Tuesday, October 14, 2008
 
 
Underscores are better for names that contains acronyms, that's for sure. For example,

URIAdapter

versus

URI_Adapter

That being said, I prefer the Java syntax above all else. I find it the most readable syntax for most cases, acronyms being the obvious exception. I use underscores for database tables/rows and camel-case for my Java code.
Gili Send private email
Tuesday, October 14, 2008
 
 
For all of the do as the Romans do commenters do you _ or camel in C++?  The standard lib _s but most code I see camelCases.
soup
Tuesday, October 14, 2008
 
 
Wikipedia has some explanations:

http://en.wikipedia.org/wiki/CamelCase

[The "Lazy Programmer" theory

One theory for the origin of the camel case convention holds that C programmers and hackers simply found it more convenient than the standard underscore-based style.

Indeed, the underscore key is inconveniently placed in most keyboards. Additionally, in some fonts the underscore character can be confused with a minus sign; it can be overlooked because it falls below the string of characters, or it can be lost entirely when displayed or printed underlined, or when printed on a dot-matrix printer with a defective pin or misaligned ribbon. Moreover, early compilers severely restricted the length of identifiers (e.g., to 8 or 14 letters), or silently truncated all identifiers to that length. Finally, the small size of computer displays available in the 1970s encouraged the use of short identifiers. It was for these reasons, some claim, that many C programmers opted to use camel case instead of underscores, for it yielded legible compound names with fewer keystrokes and fewer characters.]
Secure
Wednesday, October 15, 2008
 
 
And then there's Lisp and with-open-file ...

There remain actively used languages that ignore case within identifiers: Ada for one, and its relative PL/SQL. For them camel-casing is just pretty printing.
George Jansen Send private email
Wednesday, October 15, 2008
 
 
If your symbol names are long enough for this to be an issue maybe you should use punchier symbol names?
Rowland
Wednesday, October 15, 2008
 
 
"Because underscores in method names looks stupid"

That translates to me as "I've been looking at camel-cased code for so long that English looks foreign to me!"

Opinion noted, but not considered a very good answer.

On second thought I asked why do people hate underscores, not why should I use (or not use) them.
Wes Groleau
Wednesday, October 15, 2008
 
 
Thank you all.  I see a few reasonable if not compelling arguent, but a lot that are not so reasonable.  Not interested in general in a flame war about which is which, but I can't resist commenting on the caps lock key:

If someone complains they don't like the underscore because you have to shift, and I counter that the same argument opposes camelCase, isn't it a bit strange to suggest that I use TWO presses of the caps lock as an improvement over one press of the shift key?
Wes Groleau
Wednesday, October 15, 2008
 
 
"Not in Ruby they don't."

Still looks stupid.

Camel case naming is easier to grok quickly for me than underscores. If you like underscores, knock yourself out.

Wednesday, October 15, 2008
 
 
"If someone complains they don't like the underscore because you have to shift, and I counter that the same argument opposes camelCase, isn't it a bit strange to suggest that I use TWO presses of the caps lock as an improvement over one press of the shift key?"

I think they missed the point. The shift isn't the problem with underscores, it's the second finger movement to the top row before the third to the next letter. With camel case the second movement is omitted. Makes a significant difference in speed for me.

To be honest, I have never met someone who actually hated underscores. Are underscore "haters" common?
Craig B Send private email
Wednesday, October 15, 2008
 
 
I don't like underscores because space or commas are a delimeter between elements, and a function Name_With_Four_Words() looks like four objects at a quick glance instead of one function.
John
Wednesday, October 15, 2008
 
 
"To be honest, I have never met someone who actually hated underscores. Are underscore "haters" common?"

Rhetorical exaggeration.
Wes Groleau
Wednesday, October 15, 2008
 
 
"often want to name your methods after the data that it operates on"

Not me.  I personally want to name my methods and objects for what they do or what they represent.  If I need an employee's first name, I would prefer to reference

Employee.First_Name  or  First_Name(Of => Employee)

getFirstName is a verb, yet so many shops mandate using just such a verb for all functions, even though they can only be invoked where a noun makes more sense.

In a team, I go along with the style of my team.  To expect someone else to constantly think "Wes wrote this, so I have to remember to not use camelCase" would certainly affect productivity.

But when I'm on my own, the closer to English I can make my code, the better off I am.  Underscores (which vaguely resemble spaces) are another example of that.
Wes Groleau
Wednesday, October 15, 2008
 
 
"The other problem with underscores is they're hard to say.  If you're discussing variables out loud in a code review, My_Var and MyVar sound a lot the same, unless you say "My-underscore-Var", which is awkward."

As you correctly pointed out, allowing identifiers to vary only by underscore-or-not between words is confusing and therefore should not be done.  You do it one way or the other consistently, and you don't need to pronounce the underscore.

The same argument (both paragraphs, yours and mine) should discourage identifiers that differ only be case (upper/lower).

"Forbidding underscores thus has some value to it."

But requiring them has the exact same value.
Wes Groleau
Wednesday, October 15, 2008
 
 
I only use them in constants, since all upper is near impossible to read.

MAXVALUE
MAX_VALUE
Jon
Wednesday, October 15, 2008
 
 
"On second thought I asked why do people hate underscores, not why should I use (or not use) them."

Something like firstName, in English, is two words.  But to a programmer (and the programming language) that's a single symbol.  Adding underscores just muddles up that distinction.

Humans read entire words at once; we process the entire shape of the word rather than parsing out the individual letters.  Therefore, we read firstName altogether, which if you're programming, is probably exactly what you want.  Split it with underscores, and you're now back to reading two words for a single symbol.
Almost H. Anonymous Send private email
Wednesday, October 15, 2008
 
 
I prefer camel-case.  I do not hate underscores.

Underscored names are longer.  Underscored names are more difficult to type, because of the location of the underscore key.

YMMV.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Thursday, October 16, 2008
 
 
I grew up with underscores.  They were widely used in VAX/VMS and in earlier DEC environments.  I find them more readable than CamelCase or PascalCase. 

But it's probably just what I'm used to.
Walter Mitty Send private email
Friday, October 17, 2008
 
 
This is an example of the kind of trivial thing that should be handled by the editor.  It shouldn't matter which convention is actually being used in the underlying source code -- each programmer should just see what s/he personally finds easiest to read.

Emacs can do this, of course.  Can't other editors?
Iago
Friday, October 17, 2008
 
 
If I'm using camelCase or PascalCase, I'm typing different letters and alternating which shift key I use.

If I'm using underscores, I'm typing the same shift key and the same underscore key each time.

The latter is obviously more fatiguing.
Kyralessa Send private email
Friday, October 17, 2008
 
 
"This is an example of the kind of trivial thing that should be handled by the editor. "

So are you telling me that emacs automatically changes:

void this_is_a_method_name()

to

void ThisIsAMethodName()

based on the user's preference?

And that emacs is smart enough to change every instance in every source code module instantly?

Really?
Karl Perry Send private email
Saturday, October 18, 2008
 
 
Here's a related question. Why do Java coders seem, indeed, to hate underscores; but SQL schema developers seem to love them? Is this because some SQL's are case-insensitive or something like that? (Mine's not). Or is this just something particular to where I work?
Greg Send private email
Monday, October 20, 2008
 
 
"de gustibus non est disputandum"

It's what you're used to, and what fits in with the code you are working on. And who cares? The semantics of the code is what is going to give you real grief, not the format.
Graham Asher Send private email
Tuesday, October 21, 2008
 
 
I use underscores for the simple reason that it is what I am used to. When I started in computers in the early 1970s everything was uppercase only, so underscores were the only way to separate one word from another in variable or function names.

It wasn't until I moved from mainframes to mini-computers (which later became micro/personal computers) that both upper and lower case were possible, but both the COBOL compiler and operating system were case insensitive. We tended to use upper case for all code and lower case for all comments.

All the early database systems, and even the modern SQL databases, are case insensitive, so the use of CamelCaps was seen as a total waste of time, which is why we stuck to underscores.

PHP is the first programming language I have used which is sensitive to case, and I find it totally frustrating!!! That is why all my code is lower case and I still use underscores.

CamelCaps give me the hump!
Tony Marston Send private email
Wednesday, October 22, 2008
 
 
Gnu standards ask for underscores, in particular because identifies with underscores are easier to scan for those not so familiar with English.


Only problem, the underscore requires a shift, which_is_a_pain_when_typing_fast.
What is this Web stuff, anyway
Tuesday, October 28, 2008
 
 
+1 asmguru62

I find that underscores look similar enough to whitespace that when one is scanning a long line of code it all seems to run together. In general I tend to prefer camelCase for C+/C# code.

That said, I'm happy programming in Python and haven't run into problems using the underscore convention that seems to rule in that community. Maybe the whitespace problem asmguru62 mentions is lessened somewhat by Python's preference for lowercase? Python code with lowercase & underscores seems to have a cleaner, more readable appearance, to me at least.

I think we should talk about something really important like where the braces should go? :-)
Phil Lodine Send private email
Friday, October 31, 2008
 
 
I say "tomato" you say "toma_to"
Dan
Friday, October 31, 2008
 
 
Because they are so low.

Thursday, November 06, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz