CamelCase vs underscores: Scientific showdown

In the odd case that you are an experienced programmer who doesn’t have a preference over using camel case or underscores for identifiers, try making up your mind now. Try choosing independently of (language) convention, habit or type of the identifiers. If you are a Lisper and like dashes, just vote for your next favorite.

if ( thisLooksAppealing )
    youLikeCamelCase = true;
    votePoll( camelCaseFormatting );
else if ( this_looks_appealing )
    you_like_underscores = true;
    vote_poll( underscore_formatting );

Did you vote? Good! Now it’s my turn to do some work, as I will try to take you through a semi-scientific explanation to prove which formatting is best suited for programming.

I wouldn’t have written this post, if I hadn’t read Koen’s Tao of Coding. As an ex-colleague he converted me to the underscores camp. The trigger to write this post was when reading a reply on a formatting discussion.

“honestly the code is easier to read” Opinion or fact?

It inspired me to look for scientific resources. Surely, studies must have been done right? As it turns out, not too many, but I found one. But first, in case you never had this discussion, … the usual opinions, and rebuttals. If you are looking for the facts, skip to round 3.

Round 1: The opinions

Pro underscores

  • Underscores resemble natural writing the most, and thus are more readable. Spaces are simply replaced with underscores. Extreme example: isIllicitIgloo vs is_illicit_igloo.
  • Consistency with constants. Underscores are still needed in all-caps naming conventions. E.g.: THIS_IS_A_CONSTANT
  • Abbreviations could still be kept uppercase easily. E.g.: TCP_IP_connection vs tcpIpConnection
  • Classes can be kept camel case, giving a clearer difference between them and identifiers/functions. E.g.: CamelRider.ride_camel() vs CamelRider.rideCamel().

Thank you, Yossi Kreinin, for the last two points, as discussed in IHateCamelCase.

Pro CamelCase

  • Camel case is easier to type, and underscores are hard to type.
  • Camel case makes paragraphs easier to read. my_first_variable=my_second_variable-my_third_variable vs myFirstVariable=mySecondVariable-myThirdVariable
  • Camel case is shorter.
  • Camel case is used by convention in a lot of major languages and libraries. (You weren’t allowed to use this argument when voting!)

Round 2: Rebuttals

Anti underscores

  • Underscores are ugly, camel case is more elegant.

Anti CamelCase

  • Underscores aren’t that hard to type. Seriously, as a programmer it is your duty to learn blind typing with all ten fingers. Learn qwerty, and save yourself the trouble of having to use the exotic AltGr button.
  • Use whitespaces and an IDE with color coding to easily see the difference between operators and identifiers.

Round 3: The facts

When reading the abstract of the research paper, it seems science is on the camel case side.

Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.

Existing research

Natural language research in psychology found that replacing spaces with Latin letters, Greek letters or digits had a negative impact on reading. However, shaded boxes (similar to underscores) have essentially no effect on reading times or on recognition of individual words. Removing spaces altogether slows down reading 10-20%.

Experiment setup

Empirical study of 135 programmers and non-programmers. Subjects have to correctly identify a matching phrase (maximum of 3 words long) out of 4 similar phrases. The important variables researched:

  • Correctness: whether the subject identified the correct phrase.
  • Find time: time taken to identify the phrase.
  • Training: how being a programmer affects the performance.


  1. Camel casing has a larger probability of correctness than underscores. (odds are 51.5% higher)
  2. On average, camel case took 0.42 seconds longer, which is 13.5% longer.
  3. Training has no statistically significant impact on how style influences correctness.
  4. Those with more training were quicker on identifiers in the camel case style.
  5. Training in one style, negatively impacts the find time for other styles.

The paper concludes:

Considering all four hypotheses together, it becomes evident that the camel case style leads to better all around performance once a subject is trained on this style. Training is required to quickly recognize such an identifier.


Personally, I find the conclusion flawed for a couple of reasons.

Correctness isn’t of much importance when programming. Correctness refers to being able to correctly see the difference between similar identifiers. E.g. startTime vs startMime. This is not a common scenario when programming. Additionally, with modern IDE’s you have auto completion and indications when a written identifier doesn’t exist. This makes me believe results (1) and (3) are irrelevant. As a sidenote, I believe the correctness of camel casing is due to the slowness of the reading. When you need to take more time to read something, you will read it more accurately.

When discussing possible threats to validity they mention the following. “Essentially all training was with camel casing, it would be interesting to replicate the study with subjects trained using underscores.” Result (4) and (5) just seem unfair when taking this into account. Isn’t it obvious that people who are used to camel case are better at it. Additionally, it has a proven negative impact on the “find time” for underscores.

So, only the slowness of reading camel case (2) remains. It takes 13.5% longer on average to read a camel case identifier than an underscore identifier. Multiply this for entire code blocks, and you have my semi-scientific opinion on the war between camel case and underscores!

For those brave enough to stick around until the end, what is your opinion now? Again, try choosing independently of convention, habit or the type of identifiers.P.s.: If you still believe camel casing to be more appropriate for programming, it would be interesting to leave a comment with argumentation.😉 I could update “Round 2: the rebuttals” to include your comments to make the article more balanced.

Update: I’ve discussed a follow-up study in a new post. They reproduced the study and measured it takes 20% longer on average to read a camel case identifier, and additionally using eye tracking they identified camel case identifiers require a higher average duration of fixations.

  1. #1 by Ali on February 21, 2011 - 12:16 am

    Thanks for this. I personally don’t mind either. But a single study isn’t “fact” or “science”.

    • #2 by Steven Jeuris on February 21, 2011 - 3:17 pm

      Well, it is a study following the scientific method. Furthermore, it references existing research in natural languages from which can be inferred that underscores should be more readable. Their result of 13.5% slower reading corresponds to existing reseach which measured slower reading in the range of 10% – 20%.

  2. #3 by Mia on February 26, 2011 - 1:55 pm

    I think you’re forgetting (4) Those with more training were quicker on identifiers in the camel case style.

    • #4 by Steven Jeuris on February 26, 2011 - 4:35 pm

      Hi! Thanks for the input, but I do mention why I drop it in the discussion. “Essentially all training was with camel casing, it would be interesting to replicate the study with subjects trained using underscores.” Result (4) and (5) just seem unfair when taking this into account. Additionally, I found a recent follow up study “An Eye Tracking Study on camelCase and under_score Identifier Styles” which attempts to solve these issues, and underscore casing comes out on top. Once I have time to analyze it I will update the blog post.

  3. #5 by Pi on November 3, 2011 - 12:30 pm

    I can’t decide what is better but I think research (2) has nothing to do with camelCase. “replacing spaces with Latin letters, Greek letters or digits had a negative impact on reading” means camelxcase or camel4case, and later “Removing spaces altogether slows down reading”. True as you can see with camelcase. But all this is not camelCase.

    • #6 by Steven Jeuris on November 3, 2011 - 1:18 pm

      I’m not 100% sure, as I read the papers a long time ago, but I recall that the part you are referring to is only a summary of previous natural language research. The findings from (2) are not the findings of the scenario you described, but from the experimental setup of this paper, which does compare camelCase with under_score.

  4. #7 by Fidel on April 22, 2012 - 10:57 pm

    With CamelCase it is more simple for me to distinguish the number of identifiers easily. In Haskell, where a space between two identifiers means function application that is a killer example.
    a_function_with_a_very_long name_applied_to an argument_with_a_similarly_long_one
    a_function_with_a_very_long_name_applied_to an_argument_with_a_similarly_long_one
    a_function_with_a very_long name_applied_to_an_argument_with_a_similarly_long_one

    Which one is correct?
    Now, in CamelCase…
    aFunctionWithAVeryLong nameAppliedTo an argumentWithASimilarlyLongOne
    aFunctionWithAVeryLongNameAppliedTo anArgumentWithASimilarlyLongOne
    aFunctionWithA veryLong nameAppliedToAnArgumentWithASimilarlyLongOne

    None is too simple, but when reading carefully the CamelCase one, it can be discovered more easily which one is correct (perhaps due to the fact that identifiers for variable things in Haskell start with lowercase…)

    To conclude showing you how different the 3 things are, the same 3 examples above, with one single letters:
    f x y z
    g a
    h i j


    • #8 by Steven Jeuris on April 22, 2012 - 11:07 pm

      That basically boils down to “Camel case makes paragraphs easier to read.” as mentioned in the ‘Opinions’ section. As I reply in ‘The Rebuttals’ section: “Use whitespaces and an IDE with color coding to easily see the difference between operators and identifiers.” Different semantic meanings of keywords can easily be visualized in modern IDEs. I present this case even more strongly in “The code formatting fallacy”:

      • #9 by Xah Lee (@xah_lee) on February 16, 2013 - 4:23 pm

        yeah but given a IDE or editor, it doesn’t necessarily color user variable. Most likely not, in most languages.

    • #10 by Jim J. Jewett on April 25, 2014 - 7:49 am

      All the more reason to to use such long identifiers. Even so, these wouldn’t be as bad in a language that used more syntax.

      a_function_with_a_very_long(name_applied_to, an, argument_with_a_similarly_long_one)
      a_function_with_a(very_long, name_applied_to_an_argument_with_a_similarly_long_one)

      aFunctionWithAVeryLong(nameAppliedTo, an, argumentWithASimilarlyLongOne)
      aFunctionWithA(veryLong, nameAppliedToAnArgumentWithASimilarlyLongOne)

  5. #11 by Fidel on April 22, 2012 - 11:01 pm

    Oh, btw!! In case of doubt, for example, in those strange cases, I favour a mixed style.



    And I am a programmer, yes…😀

    • #12 by Steven Jeuris on April 22, 2012 - 11:12 pm

      That is actually mentioned as one of the ‘pro’ arguments for underscores: “Abbreviations could still be kept uppercase easily. E.g.: TCP_IP_connection vs tcpIpConnection” I really dislike mixing the two, but of course all of that is highly subjective.:)

      • #13 by Someone on November 16, 2013 - 7:29 pm

        You’re messing up with constants, as long as you’re not writing PHP or similar and have a $ in front of vars anyway.

  6. #14 by Steve Skwire on May 24, 2012 - 9:54 pm

    An argument in favor of underscores that I haven’t seen in this discussion concerns how you SAY the variable name in ofr example a code inspection. If you have a variable one_two_three, one would say “one underscore two underscore three”. On the otherhand, how does one say oneTwoThree in a way that distinguishes it from onetwoThree.

    • #15 by Jacob on February 15, 2013 - 12:27 pm

      That’s not fair. How you distinguish “one_two_tree” from “one_Two_three” ?

    • #16 by Tim Inman on February 15, 2013 - 1:49 pm

      The first answer is that you would never choose onetwoThree as a variable, it is against convention. The other is that variables are for reading and typing, not really for speaking, anyway.

      • #17 by Steve Skwire on February 15, 2013 - 4:14 pm

        If you ever use code inspections, or even discuss your code with your colleagues it is sometimes necessary to talk about your code and speak the names of the identifiers.

    • #18 by Jim J. Jewett on April 25, 2014 - 7:59 am

      I tend to pronounce — even in my own head — underscores with a slight pause, similar to spaces or hyphens. I tend to read CapCase with a bit more stress on the capital letter — it is internally “louder”. That does mean that my preference (and error rate) is affected by how tired I am, and by how “far” I have to keep it in mind. (Matching to a few lines up on the screen favors CapCase; retyping it in another program favors under_lines.) Of course, actually switching at such times would be folly, but it does mean that the artificial situation used in the tests for the papers above is even more of a problem.

      This “CapCase is louder” convention does happen to work well with the convention of using a capital to indicate the type, and a lower case to indicate an instance.

  7. #19 by Rasmus Bååth on June 5, 2012 - 12:24 pm

    An eye tracking study from 2010 using a similar methodology also supports using underscore.

    • #20 by Steven Jeuris on June 5, 2012 - 12:29 pm

      Thank you for the link! I found the same study a while back, and mentioned it in a previous comment as well. Given the popularity of this post I should probably best incorporate it at some point, or write a follow up post. Unfortunately I’m quite busy finishing up my thesis at the moment.:)

  8. #21 by Mircea Lungu on July 3, 2012 - 12:10 pm

    I liked the article, and the fact that you seem to have converted 5% of the CamelCasers to underscore_users:)

  9. #22 by Praveen on July 19, 2012 - 7:05 am

    A java programmer working with large java code base(library,JDK…), everything is in camel case & I think decision has already been made & pushing underscores makes a deviation that majority won;t like.
    Although I liked the argument for underscore, democracy and context (for java programmers) triumphs over correctness:)

  10. #23 by reign85 on July 25, 2012 - 10:25 am

    I use camel case for identifier and underscore for functions =)

  11. #24 by James on September 29, 2012 - 12:01 pm

    “Underscores aren’t that hard to type. Seriously, as a programmer it is your duty to learn blind typing with all ten fingers.”

    I’ve got quite short little fingers (my other fingers aren’t exactly those of a pianist either), so underscores actually ARE significantly harder for me to type – they require me to move my entire right hand. The plus/equals key is even further away – but I don’t need to type nearly as many of those!

  12. #25 by jpnorair on October 31, 2012 - 11:08 pm

    In my experience, more better coders use underscore. Camel case seems to have cropped-up from Java, mainly.

    By the way: I type Dvorak. Underscore method is even better on this layout. High level programming syntax, in general, is better on Dvorak due to convenient placement of punctuation keys.

    • #26 by Anonymous on March 3, 2015 - 7:09 pm

      I don’t disagree, but this argument can be taken too far. The best programmers I’ve ever met all knew Lisp (and used it seriously at some point in their careers). Therefore, in my experience, better coders use dashes.

      I use Dvorak, too, and I know a lot of programmers who do. With how much faster and more comfortably I can type, I kind of wonder why anyone doesn’t. I think it’s interesting that so many programmers avoid learning a keyboard layout, when it’s less effort than (really) learning a new programming language or text editor or web framework — things that many do once a year just to keep their minds in shape.

      • #27 by Steven Jeuris on March 4, 2015 - 2:00 am

        Because arguably the main bottleneck in coding is not writing the actual code, but rather forming the required abstractions. Regardless, I have a similar opinion when it comes to touch typing. “Not being able touch-type as a programmer is like a cook who takes ages to slice his food up.”

  13. #28 by Bernard on February 15, 2013 - 6:46 am

    I like the underscore style for its readability but there are a couple of reasons why I use camel case:

    1- If you’re programming in C, some compilers limit the maximum function name to 32 characters. This is a concern especially in embedded systems. If you’re going to prepend your functions with the module they are associated with, you start running into this limit.
    Ex: SerialPortIsTxBufEmpty vs serial_port_is_tx_buf_empty

    2- Most coding standards have a limit on the maximum width of a line (usually 80). Using underscore makes your line length much longer and forces you to break your statements into multiple lines, which is less readable. Using camel case allows you to put a little bit more on a single line. This is most noticeable when using nested if statements (which may not be as used in languages other than C).

    • #29 by Steven Jeuris on February 15, 2013 - 2:51 pm

      Although the arguments sound a bit dated they are relevant nonetheless. Thanks! I personally don’t use the 80 characters limit. With the screen resolutions lately you can easily fit 130 character and still have all your tool bars open.

  14. #30 by Miles Bader on February 15, 2013 - 9:55 am

    Note that Emacs has “glasses-mode”, which will dynamically insert underscores into CamelCase’d identifiers at display-time…

  15. #31 by jhsowter on February 15, 2013 - 12:05 pm

    Font makes a difference. Camel case is probably harder to read if the font is narrow. I wonder how the study controlled for this?

    Some people mentioned that underscores aren’t really “hard” to type if you can touch-type. But surely “hard” means “slower” or “more prone to error” rather than “makes my fingers hurt.” If that were true, it would be an argument against underscores.

  16. #33 by Jacob on February 15, 2013 - 12:43 pm

    I usually prefer camel case. But if i work on other people code and they use underscores I can easily switch and have no problem adapting. The thing is I usually don’t use long variable and function names and prefer to shortcut obvious words and doing that just looks better with camel case. A dumb example would be a variable called account name. You can have it aName vs a_name or acntName vs acnt_name which just looks weird with underscore. But like all others it’s just a matter of taste/habit/ide/language/native language/etc and if you do it one way or the other you’re gonna be good at it and those reading/understanding times will drop.

    It would be interesting to see the style of all the big/popular open source repos where many people commit and read code from and also grouped by programming language.

  17. #35 by Some guy on February 15, 2013 - 2:01 pm

    Funny that the pro-underscore argument suggests using camelCase for class names. So the article reads more like usingCamelCase_sometimes vs usingCamelCase.

    • #36 by michaeljsouth on August 20, 2013 - 12:57 am


    • #37 by Jim J. Jewett on April 25, 2014 - 8:09 am

      usingCamelCase_sometimes is the monster of in-between. More typical would be a single initial capital, such as:

      account_balance = new Account_balance()

      and it works better if most of your classes are named without any joiners

      username = new Username()

  18. #38 by Deryl Spielman on February 15, 2013 - 10:53 pm

    Are we really that concerned with the speed of typing? So I could type an entire program 13% faster using underscores, but unless everything is automated there will still be a variable amount of time for someone to approve the work or even get it into production. Is there that much productivity gained?

  19. #40 by Samuel A. Falvo II on February 15, 2013 - 11:10 pm

    my.favorite := useUnderscoresToIndicate_toCamelCap_(“parameters”, “keywords”);

    Some would say this combines the worst of both elements. I say it combines the best features. You’re literally “filling in the blanks,” and using long symbol name support for what it was intended for — human-readable code.

  20. #41 by Alex on February 16, 2013 - 8:09 pm

    As a long-time Perl programmer I fall firmly in the underscores_for_names camp, but also in the $sigils @make %everything &more *readable camp. The fact that in other languages (C, Java, Python, Ruby) you can’t immediately see that a variable is a $scalar, @array or %hash is really weird to me and I find it much harder to read!

  21. #42 by Neil in Chicago on February 24, 2013 - 8:49 pm

    “Sometimes it’s more important to have a standard than to have the best standard.”
    It is *far* more important that there be an enforced shop standard so that everyone writes the same way.

    • #43 by Steven Jeuris on February 25, 2013 - 3:48 pm

      Obviously. But that’s why I started out in bold with: “independently of (language) convention, habit or type of the identifiers”. You aren’t the first to point out the importance of conventions. Look at the highest up voted answer on the post I linked to in the introduction. As I stated, I was merely interested in scientific resources, as that is something that I haven’t found discussed before, hence the desire to contribute in this way to the discussion instead of yet another subjective post on the topic.

  22. #44 by Rich Shealer on March 2, 2013 - 3:31 am

    I think one reason that I like camelCase better is that the variables look like single entities. The under_score versions tend to break apart into separate words in my mind. This takes more to sort out. I realize that IDE coloring helps this somewhat, but looking at code in other areas such as in the voting example above I don’t have those cues to work with..

  23. #45 by Geoffrey A. on May 29, 2013 - 8:30 pm


  24. #46 by Jubo on July 11, 2013 - 3:02 pm

    I think you forget that speed of reading isn’t everything. Research on text reading shows that sentence/line length, word length, and word “difficulty” (whatever that can be; depends strongly on context and reader) have a strong effect on comprehension. Furthermore, words are easier to distinguish, if they differ towards their beginning. This seems to favour camelCase. That reading takes longer for camelCase might mean that people are forced to read more carefully and therefore remember/distinguish better … IMHO, finding a “good” identifier is more important than camelCase versus under_score. There is quite some recent research on naming. Check it out.

    • #47 by Steven Jeuris on July 11, 2013 - 3:20 pm

      Indeed, speed of reading isn’t everything, but your remarks apply to both casing styles and thus don’t need to be controlled for. However, I don’t understand your reasoning that words differing towards their beginning are easier to distinguish, thus favoring camelCase. Perhaps I am missing something? Why would startTime / startMime, be easier to distinguish than start_time / start_mime? One could even argue since using underscores it more resembles two separate words it is easier to distinguish. However, I also mentioned, albeit tongue in cheek, “As a sidenote, I believe the correctness of camel casing is due to the slowness of the reading. When you need to take more time to read something, you will read it more accurately.”, so I might agree with you there. ;p

  25. #48 by Jubo on July 11, 2013 - 3:07 pm

    PS. I forgot one thing regarding the voting on the web page.
    The comparison is not fair. If “camelCase” is used as one alternative, then the other one should be “under_score” and not “underscore”. I’d consider this as a threat to validity, since it gives all identifiers of the under_score group fewer parts than the identifiers in the camelCase group.

    • #49 by Steven Jeuris on July 11, 2013 - 3:13 pm

      I think there are worse threats to validity than that using this online poll.:) There is no underscore in between “under” and “score” since it’s one word.

  26. #50 by piyo314 on August 6, 2013 - 2:56 pm

    Overall, I’m on the fence, but I find this point to be rather weak:

    “Underscores aren’t that hard to type. Seriously, as a programmer it is your duty to learn blind typing with all ten fingers. Learn qwerty”

    Coders who use camel case *can* type. They know qwerty. However, if something is awkward, you will always be slower at it than you could be at a non-awkward alternative.

    Also, I can apply the same rebuttal to underscore’s reading speed benefit: “Camel case isn’t that hard to read. Seriously, as a programmer it is your duty to learn to read all kinds of code. Learn to read code!”

    • #51 by michaeljsouth on August 20, 2013 - 12:54 am

      Actually underscores are (or can be) easier to type. You only have that one thing you hit the shift key for, so you always shift with your left pinkie and if you’re hitting shift, your right hand knows where that finger is going, to the only thing you shift for in a variable name.

      • #52 by Pharap on November 8, 2013 - 10:25 pm

        As easy, not easier.
        Also, some languages start variable names with symbols like $ and @, so it’s not the only thing you ever shift for.

      • #53 by michaeljsouth on August 18, 2015 - 9:52 pm

        It’s true that with Perl 5’s sigils you have to type shifted characters at the beginning of the variable name; what I was referring to was the actual name itself. In camel case you’re having to shift at any letter starting a new word, which would be “shift+whatever-letter-of-the-alphabet-is-needed”, which is a lot more “stuff” than being able to hit one frequently used shifted character. Also, you’re going to have to type those sigils anyway, and they share this characteristic with the underscore, in that they are a limited set of very frequently used characters.

  27. #54 by Michael on November 3, 2013 - 12:24 am

    I think that a more fair comparison would be had if most languages were not case-sensitive. In that case, I would consider camelCase as superior to underscores. (since there is no case error situation possible) Otherwise, I like underscores more.

    • #55 by Brilliand on November 8, 2013 - 3:17 am

      In languages that aren’t case sensitive, camelCase is dangerous because of the possibility of collisions (i.e. between thisOldMan and thIsOldMan). Underscores are then needed to work around that flaw in the language.

      This is a reason not to use camel case for PHP class method names in particular, which is what I was thinking about when I came here…

    • #56 by Pharap on November 8, 2013 - 10:21 pm

      But most languages are case sensitive, primarily for the reason that uppercase and lowercase letters are encoded differently. Unix is a large factor in this and until Visual Basic nobody actually bothered with case insensitivity because many programmers find case insensitivity to be more restrictive than case sensitivity.

  28. #57 by Pharap on November 8, 2013 - 10:13 pm

    As someone with an A level in psychology, I can tell you that “shaded boxes (similar to underscores)” doesn’t cut it. That is what is known as a ‘generalisation’ and making generalisations gets you laughed out of the debate room frankly.

    As a programmer I could tell you that if there was a shaded box button, I would prefer it to the underscore button (providing it wasn’t as far away as the escape key or the number pad).

    I accept your argument that underscores aren’t too hard to type, in fact the underscore shares its button with a common operator and is no further away than the += button.
    Personally I would argue that because it is a symbol it looks too much like an operator to be acceptable in identifiers. By extension I would also argue that the dollar sign or pound sign should not be used unless the language in question uses it for a specific reason (such as perl’s use of $ to identify scalar variables).

    I do not accept “Use whitespaces and an IDE with color coding to easily see the difference between operators and identifiers” as an argument. That is a work around, not an argument. Particularly the “Use whitespaces” part, as many compilers purposely allow programmers to be more lax with whitespace to prevent annoying ‘incorrect syntax’ errors that slow productivity and could otherwise be avoided.

  29. #58 by Someone on November 16, 2013 - 7:34 pm

    > No discussion when a letter should be capitalized, all lowercase.

    That is no valid point. The letter should be capitalized where a new word begins, just the same as where you would put an underscore. I can’t see any difference here, just feels like seeking for arguments and not able to find some more.

    • #59 by Steven Jeuris on November 21, 2013 - 3:33 am

      That’s a good point, … Quite worrisome that after so many visits you are the first to notice.:) I don’t remember where I got that one from. I think I was merely summarizing stuff I read around the internet, but this one indeed has little foundation. It is listed in the section ‘opinions’ for a reason. ;p I’ll look into where I got it from when I have time to see whether there is any ‘stronger’ reasoning behind it, and will otherwise remove it since it doesn’t make any sense indeed, as you point out.

      • #60 by Brilliand on November 21, 2013 - 7:55 pm

        I’m sure I’ve seen discussion as to whether minor words such as “the” should be capitalized. Perhaps this could be restated as “camelCase may be confused with title case by the inexperienced”.

  30. #61 by Underscorerer on December 13, 2013 - 9:33 pm

    I have another argument in favor of underscores.

    If you have a variable by the name of “user_name”, for example, and you have a get- and set-method: “set_user_name” / “get_user_name” it becomes easier to rename your variable later on.
    You just search for all instances of “user_name” and replace them with, for example, “player_name”.

    But if your variable is called “userName” and your methods are “getUserName” and “setUserName” you have to replace “userName” with “playerName” and “UserName” with “PlayerName”.

    It isnt much, but its something.

  31. #62 by Scott Thede on March 1, 2014 - 6:50 am

    Research aside, I like CamelCase better… my reason is less clutter. I think your eyes need ‘something’ to delineate the characters into words, and since age 2 I have seen every sentence, name, place, or thing start with an uppercase letter. Uppercase means you are starting something. How else could your brain EVER see that. (Lol catch that?) However, with underscores, I have something that is suppose to represent nothing. Pay no attention to the man behind the curtain! Think about it, we see capital letters starting words everywhere in our world, but no where are underscores used, just code.

    • #63 by Steve Skwire on March 3, 2014 - 4:08 pm

      Intersting observation but I think it is a better argument for underscores than for CamelCase. Most users of camel case actually start with a lower case letter as in “thisIsCamelCase”. Users of underscores generally start with a cap as in “This_Is_Under_Scores”. Also, while as you say, things start with an uppercase letter, they actually start with an uppercase letter preceded by a blank, which is a much better description of typical underscore usage than CamelCase.

  32. #64 by Scott Thede on March 1, 2014 - 6:53 am

    One last thought… it would be an interesting experiment to ask everyday people to sit at a computer and type a paragraph. The twist is you tell them the space bar is broken, so please use something else. Would we get a bunch of underscores? Dashes? Lol just thinking about trying to type with a broken space bar makes me uber-frustrated-you-know-what-i-mean? Ahh!

    • #65 by Brilliand on March 4, 2014 - 1:27 am

      If I were looking for a normal-prose substitute for spaces, I think I’d go for commas.

  33. #66 by will on March 27, 2014 - 10:56 am

    ok i calmed down
    i figured out that the solution is neither
    underscores are better because then i can have the solution which is…

    a button on a ide or preference settings switch
    that just lets me switch everything to what ever style i feel like using that day when i load in code

    you know though no one does reverse capitalization mYOBJECT lol
    or if we had another alt type key that added strong soft sounds like the old curve over a letter
    or if we had another alt type key that put a square around a letter
    or if we had another alt type key that underlined a whole word or continuous character sequence

    im changing all the colors in vs for everything to a unique color right now

  34. #68 by Giovanni C. Hynson on April 10, 2014 - 12:17 am

    The problem lies with programming period.

    Make the programming languages more like human written language.

    If I turned in a paper written in “CamelCase” or “under_score” my professor would definitely give me an “F” in computer science class.

    Why can’t programmers figure a way for computer languages to be more like written English.

    • #69 by Anonymous on March 3, 2015 - 6:38 pm

      Programming is more like logic or mathematics than English. If you turned in a mathematical derivation that consisted entirely of full English words, your professor would probably not grade it very highly, either!

    • #70 by Brilliand on March 3, 2015 - 10:07 pm

      It’s been done – see Hypertalk.

  35. #71 by Thomas Mansencal on April 20, 2014 - 5:09 pm

    I’m having a deep internal debate about all that since a few months. My whole Python codebase is camelCase even though it’s against Pep8 recommendations (Pep8 has some strange mixes like CamelCase classes with the_class_method methods I don’t really like and my employer has a full camelCase codebase ).

    Anyway I came across some cases where underscore is superior to a strict camelCase convention:

    Let’s say that you have a definition that converts some data to sRGB color space, you would write it this way in lowerCamelCase:

    def convertDataToSrgb:

    If you want to respect the naming convention you have to change the case of sRGB to Srgb.

    With an underscore naming convention one could keep convert_data_to_sRGB.

    I have more annoying cases over my blog and would be happy to hear what you think about it.

    Basically naming a definition that converts from CIE XYZ to CIE xyY (Notice the case importance in the different colorspaces names).

    Here is the blog post:



    • #72 by Brilliand on April 21, 2014 - 5:03 pm

      The fact that camelCase takes that choice away from you seems to cut both ways (although, I think there is a valid case for camelCase with every letter of an acronym counting as its own word).

  36. #73 by W.T. Door on July 23, 2014 - 5:24 pm

    As a scientific programmer, I find that camelCase — or a mixutre, I suppose — suits my needs best. It’s important to expicitly define the units of many of the variables I work with, and I find that using camel case for the variable name with the unit tied on via underscore makes for an easy way to read the variable name (what the variable is) and the unit of measurement:

  37. #74 by massau on August 18, 2014 - 5:39 pm

    personally i prefere camelcase because the _ even on an qwerty to be really far away from the other letters. the alt gr is a god key if the underscore was on altrgr+f than it would be useful. for those why do not know where the alt gr is at it is just the right alt key and can be pressed with the thumb.

    I personally find code with the underscores more clumsy/cluttered when you see a full code block specially if pre underscores are used to set the constants.

  38. #75 by Ravi Dhoriya on September 10, 2014 - 1:33 pm

    I use undescore with variable_names and CamelCase() for functions.😉

  39. #76 by Marc on October 6, 2014 - 11:48 pm

    Recently I’ve started using Capwords with underscores. Although it seemed cumbersome at first, it is quite elegant to read :

    This_Is_Elegant_To_Read Although At_First_A_Bit_Difficult_To_Type

    Before judging, remember that code is read much more than it is written, and that we have command completion nowadays.


  40. #77 by Will Thorn on December 11, 2014 - 11:54 pm

    “Underscores aren’t that hard to type. Seriously, as a programmer it is your duty to learn blind typing with all ten fingers.”

    That has nothing at all to do with relative typing ease. This kind of thing comes up in vim/emacs discussions – how far do you have to stretch your hand, and with which finger? The shift key has to be pressed for both camelCase and underscore. With camelCase, you often hit the letter and shit with the same hand, and letters are always easier to reach, and naturally faster – everyone types letters much more often, and so you aren’t interrupting the flow of typing. For underscore, you need to stretch up to hit the underscore key, while with the opposite hand hitting shift. Interrupts typing flow.

    “You should learn to type” is no excuse for typing in a relatively less efficient manner😉

    • #78 by Steven Jeuris on December 12, 2014 - 12:24 am

      Neither is ‘difficulty of typing’ really relevant when we are talking about what is mainly readability of code. ;p

  41. #79 by simernet on January 29, 2015 - 12:53 am

    In the conversations what was left out is the probability that the underscore is often misread or misinterpreted as a space causing coding problems and headaches. This can happen in I/O systems such as input forms, Web pages, Print outs, or outside scripting/programming languages. It is no longer safe to say that we will be sticking within only one coding language or syntax method. Many people with limited nearsightedness may also misread this are will be unable to distinguish the underscore and see it as a space depending on sight, display or within a form with a frame where it gets hidden. Everyone gets older with there eyesight suffering and at the same time displays are getting smaller instead of larger these days.

  42. #80 by Anonymous on March 3, 2015 - 6:42 pm

    The research paper you cite mentions demographics briefly, but says nothing about the spoken language background of the participants.

    One of the best arguments against camelCase that I’ve heard is that it’s much harder for non-native speakers to read. I’m a native English speaker but when I’ve had to read source code written in German camelCase, even though I speak conversational German, I certainly have a bear of a time figuring it out.

    This is not just a theoretical problem. In my current professional environment, 50% of the team speak English as a second or third language. That’s actually high: globally, English is the language of source code, but far fewer than 50% of programmers speak English as a first language.

    • #81 by Steven Jeuris on March 4, 2015 - 1:42 am

      “A wide variety of students took part in the study. Based on the demographics data, they represent a fair cross section of Loyola students”, which seems to be “Loyola University of Chicago”. I would expect a majority of English speaking students, including possible exchange students who would still be proficient enough in English.

  43. #82 by Derek Chen-Becker on March 3, 2015 - 6:59 pm

    Maybe it’s because I’ve been programming in languages that primarily use camelCase for so long, but I have a lot of difficulty reading underscore identifiers. Part of it may be that I’ve trained myself to use non-alphanumeric characters to tokenize what I’m reading, and the underscore conflicts with that predisposition. When reading python code I find I have to re-read things once or twice to make sure I read it correctly.

    Also, as someone who codes a lot of Scala, the “_” is used as a placeholder for lambda functions, and Scala also allows for infix notation of code, so “foo _ bar” means something totally different from “foo_bar”: the former is a lambda invocation of “foo” with an anonymous parameter followed by an invocation of bar, whereas the latter is simply an identifier.

  44. #83 by happy technologist on March 3, 2015 - 7:03 pm

    A few things… Your first poll asks which “LooksAppealing” (or “looks_appealing”). That’s a different question than what you focused on in the article, and a different question than you ask at the end.

    Also, In Round 1, allowing the “Pro Underscore” group to take the “Camel Case is OK in x situation” is unfair, unless you let the Camel people do the same, at which point everyone is just agreeing on a hybrid and maybe disagreeing over where the hybrid lines are drawn. Cheating… deduct 5 points from Gryff^H^H^H^H^HUnderscore.

    In Round 2, the rebuttal about using text editors with syntax highlighting applies to both camps. Again you’re giving points to the Underscore camp that can be used in both places. You’re showing bias here.

    Round 3 clearly shows that the only third party research you link to sides with the CamelCase, then you dismiss their conclusions. So… again I cry bias. Also, this is an unbalanced dismissal… you argue that reading speed is more important than correctness, and I think that’s very subjective, particularly with code. Yes it’s possible to agree that a good naming convention would limit the apparent naming collisions, so limit the importance of “correctness”, so you may have a point, but you didn’t dive as deeply into the reading-speed issue. It’s possible that reading speed isn’t that important once you’re inside structured code. The experiment you linked to says “On the […] screen four clouds move around the screen. Each cloud contains an identifier written in one of the two styles under investigation.”

    This experiment is nothing like real programming. So I argue that your dismissal of the importance of correctness can equally be applied to a dismissal of the importance of speed; both are flawed proxies for overall utility.

    • #84 by Steven Jeuris on March 4, 2015 - 1:51 am

      Those questions and associated polls were just intended to frame (and initiate) the discussion. The meat of the article really lies in the presentation and the discussion of the paper, since I’ve never seen the ‘objective’ angle on this discussion before. Round one and two are just a summary of different opinions I encountered myself, and are only intended to be ‘fair’ in the sense of providing an overview of the different arguments I found online. I make no claims about them being fair or valid arguments.

      As to other studies, I didn’t find any other at the time, but posted a summary of a follow-up study two years after writing this post:

      If you find any other relevant studies, be more than welcome to post them here as I prefer steering the discussion on this post away from the subjective and towards objective results on the topic. Overall, I agree, there are some serious flaws with the methodology of this study, but the one strong result it did find (and was replicated in the follow-up study), does seem to advocate pro-underscore in this laboratory setup.

  45. #85 by alejandrocoria on March 3, 2015 - 7:39 pm

    The underscore is used to mimic spaces, but spaces are already used in programming languages to separate identifiers, reserved words and symbols. So I prefer camelCase.

    Too bad by this article on not using a monospaced font for the examples:/

    (Sorry for any mistakes, English is not my main language).

    • #86 by Steven Jeuris on March 4, 2015 - 2:02 am

      Thank you for reminding me of monospacing! Will keep that in mind for future posts which include in-line code.

  46. #87 by Earered on March 3, 2015 - 8:17 pm

    If you search for “comic sans promotes better reading comprehension ?” you’ll fond study that show that slowing reading speed might be a good idea:) So I think that the correctness part of thé mentionned study might be on an interesting track

  47. #88 by on March 3, 2015 - 8:30 pm

    Your isIllicitIgloo example is flawed because you use a font that no one in their right mind would use in a programming textpad or IDE. Try opening it in notepad++ and it is very clear exactly what it says. On the converse, convert you font to wingdings and read any of your underscored variables and they are equally unreadable.

    • #89 by Steven Jeuris on March 4, 2015 - 2:06 am

      Fair point. Those examples were just an attempted representative summary of existing opinions I found online though, and merely serve as an introduction to the study.

  48. #90 by Jessie Arr on March 3, 2015 - 9:28 pm

    As a proponent of long, descriptive variable names, I have to stick to my guns with camel casing.


    Camel casing reduces the horizontal width of your variable names, which means less horizontal scanning is needed. If the width of a variable name affects how long a programmer decides to make it, then variable names may be shortened by omitting words and therefore convey less meaning. This would be compounded in an expression that uses multiple such variables.

    Above you mention that correctness when reading variable names is not a significant factor in programming. I’d argue that while lexical correctness when parsing the text is not a big factor, LOGICAL correctness of being able to quickly grok a variable name’s origin and purpose IS a big factor.

    So if camel casing leads to variable names which are easier to understand because they contain more words (and therefore more meaning) in the same screen space, then even if they take longer to parse, they help the reader understand the code more quickly, which I would argue makes up the lion’s share of the time spent reading code.

    That said, I have no evidence of any of this, it’s just my intuition, and you asked for counterarguments. Thanks for the great article!:)

  49. #91 by B on March 4, 2015 - 12:14 am

    Some anti-underscore arguments that are deal-breakers for me:
    1. Underscores become invisible when the text is underlined.
    2. Underscores are always abused by using multiple__consecutive___underscores, _leading_underscores, _leading_underscores, identifiers consisting only of underscores, etc.

  50. #92 by Michail on March 4, 2015 - 5:49 am

    > When you need to take more time to read something, you will read it more accurately.

    13.5% slow down while reading someone else code? Yes, please.

  51. #93 by Guido Contreras Woda (@GuiWoda) on March 5, 2015 - 5:17 pm

    I think the problem was never between underscores or camel case. We need training in encapsulation and modularity, so that neither of these make a difference.

    Would you have this?
    – theVeryFoundationOfTheUniverse
    – the_very_foundation_of_the_universe

    Or this?

  52. #94 by David L. on August 25, 2015 - 3:21 pm

    I use camel case primarily, although I do use underscores occasionally, often as a delimiter in HTML. Repetitive form fields share a root ID, but then have some unique identifier tacked on to the end that I can easily parse out using the underscore.Could certainly still be done without one, but it does make it more readable in the rendered code.

  53. #95 by Dingfeng Quek on September 1, 2015 - 9:13 am

    I believe the relevant field of study is actually in typography, eye-tracking studies of reading english (or similar phonetic languages), graphics design, etc. There are many issues which are neglected in your post (and in the experiment):

    # Font and Kerning
    Choice and design of font and other aspects of typography can degrade performance for both conventions:
    1. when_using_underscores_frequently, the stroke should be thicker, and the length shorter; underscore is not designed as a word delimiter which is why its length is significantly longer than that of a space
    2. WhenUsingCamelCaseFrequently, upper-case alphabets should have a higher height (or lower-case have a lower height) for a stronger distinction; the kerning can be increased when an upper is preceded by a lower; Fonts need to be lighter in general to compensate for the increased ‘ink’ density

    Even when using fixed-width fonts (which are somehow popular with programmers), many aspects (but not underscore length) of typography still applies.

    The typography choices will strongly influence the effects of either convention.

    # Line spacing
    Bigger line spacing => advantage for underscore:
    Smaller line spacing => advantage for CamelCase: When line spacing is small, it is harder to distinguish the boundary between words. Clumping alphabets and glyphs together will improve word perception (both speed and accuracy).

    # Using capitals with underscore
    There is CamelCase, and there is Camel_case, and Camel_Case. Underscores allows greater expressiveness, and clearer contours, if they are used with upper-cases. Word contours have been identified as one of the more significant features that human visual neural circuits use to recognise words, especially words at the periphery of vision (generally things more than 15 characters away horizontally). However, I often_see_underscores_used_like_this. But_not_like_this_which_should_be_superior.

    # Font size, avg word length
    As font size increases, words become easier to perceive. However, at some point, the number of words that can fit into the field of vision decreases below the processing speed of the rest of the brain (really depends on complexity and verbosity of code). CamelCase is clearly more compact; But short-forms should be even better when there are only a few variable names (doesn’t quite work when there are like 30+ names to express, or when the language doesn’t have good aliases, like type/class-name aliases).

    # Screen Size
    Smaller screens amplifies the effects of most factors

    # Scanning vs Reading
    When the section of code is more frequently scanned than read in detail (i.e. when there is a lot of boiler plate, little logic but a list of property/config settings, depends on language), then all factors for quick word perception (contour, word length, grayscale weight, kerning) becomes more important; when reading in detail word recognition is seldom the limiting factor.

    # etc
    Quite a few other factors, see the papers and textbooks. Probably dependent on IDE and font-availability as well.

    • #96 by Steven Jeuris on September 1, 2015 - 5:06 pm

      All of these mentioned factors were controlled for. Unless you want to make the argument that one of your listed factors contributed more to the measured result, than the difference between the manipulated variable, I do not see how this should invalidate the study. They used common fonts, used in actual editors. (p.s. monospaced fonts are preferred so that indentation of brackets are aligned)

      Personally, I feel the threats to validity listed in my discussion will likely impact the study more than your listed factors. For example, you mention line spacing, but there were no multiple lines used in the study. I do agree this implies a possible lack of ecological validity, but as always, you need to interpret study results in the context of the experiment which was conducted.

      • #97 by Dingfeng Quek on February 16, 2016 - 1:11 pm

        Yes, I should have been more explicit: I do think that there is a lack of ecological validity, as there is a non-negligible interaction effect (I only elaborated the interaction effects) between the factors I listed and camelCase vs under_score. Based on the factors and their interaction effects I described, I think that in a different ecology, the effects of camelCase vs under_Score could and should reverse.

        We need to interpret the study results in the context of the experiment which was conducted, but at the same time, if we are to apply them, we also need to interpret them them in the context of our actual work. What I said does not invalidate the study – I am highlighting its very narrow applicability.

        Or perhaps my ecology is somewhat different: I code on a 42″ screen, almost entirely using distraction-free mode in Sublime Text and Vi, and turn the font-size to between 20px to 34px. I use a wide variety of programming and natural languages, and notice differences depending on the language (and whether I can open it in Sublime/Vi vs need to squint on some proprietary editor/website-that-can’t-be-zoomed).

        p.s. I’ve been using proportional fonts for coding Javascript in Sublime Text since 2 years ago, and met with no issues except being unable to tell when I’ve hit 100 characters on a line; have not switched back. Many languages + formatting-styles only benefit from indent alignment. Especially the ones that are enforceable by code-formatters and linters.

  54. #98 by Yann on September 4, 2015 - 11:21 pm

    Thank you for raising the topic and support it with actual studies.
    Being a programmer myself, I believe that the reason the 2 conventions exist in the first place is to be able to make difference about what they represent. Indeed, when programming, I follow this simple rule : camelCase for a set of values/attributes, underscore_case for an actual value. This makes my code easier to read because this way you always know what you’re talking about. It increases your efficiency for sometimes you may want to apply a value to a given set (avoids confusion). Those using AngularJS will know what I’m talking about for this rule allows you to significantly reduce your code length (using directives for example).

  55. #99 by dennis luehring on January 29, 2016 - 11:59 am

    you missed one problem with camel case:

    camel case feels to be more “aesthetic” (for many programmers) then the very technical feeling of underscore case

    BUT aesthetic not always equal informative

    underscore case is just dirty/technical enough to get better names (because there is no need to find a informativ AND good looking one)

    i personaly saw more uninformative camel case names then underscore case ones

    i think that is the camel case reason for .Net/Java – to get easier into the market

  1. The code formatting fallacy « Whathecode
  2. CamelCase vs underscores: Revisited « Whathecode
  3. Odd Lots – Jeff Duntemann's Contrapositive Diary
  4. Random Articles | siddharth's space

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: