camelCase vs snake_case

By Xah Lee. Date: . Last updated: .

Been obsessing about camelCase vs snake_case for years. Still no conclusion. Scientifically, by pop, by ease of typing, no conclusion. I've pretty much read all literature about them in past years.

Most existing lang conventions are idiotic. Their formation is pretty much by happenstance. Not by any logical basis.

Back in early 1990s, i'm deeply a believer of the snake_case. Because that is a unambiguous and reversible way to map space-separated words into computer languages shortcomings of not allowing space. Some people are thinking that lisp-style-with-hyphen-is-best, but actually no, because hyphen is used in English too. So, by using hyphen as separator, you create the ambiguity of a phrase that has hyphen in the first place. For example, stdin_stand-in

[see Hyphenated Words]

But then, around 2009 or so, i started to like camelCase. Because, it's really convenient to type.

But even so, convenience of typing shouldn't count, because that's the keyboard problem, a completely separate issue, which can be easily solved. For example, i use a emacs key system that ...........

and, but, some say camelCase is harder to read than snake_case. That's not true, because words used in computer lang are identifiers. When you_start_to_to_have_long_names_like_this, the underscore camp gets edgy, because, you are not really writing prose where each words needs to be read-over, but rather, you have a blob of things that you want to easily identify at a glance — identifiers — get it?

What is the Convention?

If there is any common practice across languages, it is that, StudCamelCase is usually for class names, while snake_case for variables. But note, functional languages don't have class. So, this is only somewhat common among imperative languages.

The other convention that's somewhat pop across languages, is ALLCAPS for constants, and _start for unused variable.

Which is Easier to Type?

If we go by ease of typing, then by default camelCase is easier to type. This is because on normal keyboards, the LOW LINE _ character requires pressing Shift and using pinky finger.

However, this is easily fixed, if you have a easy key that inserts _ directly. e.g. On many batman keyboards you can do this. Then, snake_case is actually easier to type than camelCase. (but, if you turn on sticky keys, then camelCase may be easier again.)

computer language char frequency-s372x168
Computer Languages Characters Frequency

Which is Syntactically/Semantically Better?

But if we go by which is textually better, then snake_case is better. Because

  1. It is syntactically simpler, by using a delimiter.
  2. It is semantically simpler, no XMLHTTPConnection vs XmlHttpConnection issue.
  3. Does not require the complexity of capital case. e.g. Can be used on Chinese, or any alphabet or symbol set that does not have cases.
  4. You can still have the freedom to use capital case, to create different syntactic class of tokens.
  5. Can be used universally. e.g. All computer systems accept low line character. But they may not accept capital case or has complex rules about case sensitivity.


am fond of the low_line, because it's a nice char that connect chars, exactly for that purpose in computing. while the dash, has other meanings in English, and is often not allowed (because it confuses with minus sign).

Which is Visually Better?

However, for programing language identifiers, i often came back to camelCase, because:

programing language identifiers are blobs, because, you are not really writing prose where each words needs to be read-over, but rather, you have a blob of things that you want to easily identify at a glance — identifiers — get it?

In fact, there is advantage that it not be full English words, because it's impossible to name function and variable so that they fully describe what purpose they serve. Rather, you name them, as a identifier, a blob, as ID. The English in it serve as a reminder what function or variable is used for.

To illustrate, problem with snake_case is you_start_to_to_have_long_names_like_this or nobody_actually_use_fully_descriptive_words_as_function_names. With camelCase, by its very nature, you don't try to do that. and when they both are “same”, camelCase is shorter and easier to identify. e.g. YouStarttoToHaveLongNamesLikeThis.

What Does Scientific Studies Say?

There are a couple of somewhat scientific studies on camelCase vs snake_case on accuracy or speed of recognization. But is inconclusive.

Here is a the generic ones, not including language specific guides.

[An Eye Tracking Study on camelCase and under_score Identifier Styles By Bonita Sharif And Jonathan I Maletic, Department Of Computer Science, Kent State University. At , accessed on 2015-09-07 ]

[To CamelCase or Under_score By Dave Binkley, Marcia Davis, Dawn Lawrie, Christopher Morrell. At , accessed on 2015-04-15 ]

[Why the Twisted coding standard is better than PEP8 (although you still shouldn't care) By Glyph Lefkowitz. At , accessed on 2015-04-15 ]

[IHateCamelCase By Yossi Kreinin. At , accessed on 2015-04-15 ]

Wikipedia CamelCase

Wikipedia Snake case

after reading them all, all the reasons are like hogwash.

Be Consistent??

, there's iseven though there is no general agreement, but in pop blogs you find this one universal advice: : be consistent. Actually, that has no scientific basis whatsoever. I think mix use is better, because it decrease uniform shape, so it's easier to find names.

Letter Case in Programing Languages




mixed camelCase and snake_case

See also: Programing Language Popularity 2017

on the naming of the char _ , Underscore vs Low Line

Now working on my website for few hours. Currently working on new xbows keyboard page. Their official name is X-Bows. I think better is XBows. I noticed the millen gen no like hyphen, lowline, em-dash, curly quotes, or any unnecessary punctuation.

By the way, the char _ was called underscore by hackers, but its unicode name is lowline. I think that's a better name. I started to use the new name for this char.

Unicode: Punctuations • ✓ ™

yeah, i understand the underscore. But, you have to consider generation rising. This is how society changes. Younger gen dunno about what you know, and do not share your experiences. What i am doing, is observing and writing out my observation. Right now, about the naming of the char _. Now, Unicode named it LOW LINE. First of all, consider intuitiveness of a terminology. Low Line is obvious. Underscore is less obvious. Then, we consider what Gen Z will call it. Now, gen Z likely don't know what is ascii anymore. They grew up with unicode. So, they see the name Low Line. It's the older gen, who may not be too familiar with unicode, and perhaps never heard of the char name Low Line. (you guys, actually)

so, what am saying, is, likely, perhaps starting around now, or say 2025 or 2030, the name for the char _ familiar to most people in work force, will probably be Low Line, not underscore.