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.

Results

  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.

Discussion

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.

About these ads
  1. #1 by Mapson on February 17, 2011 - 11:04 am

    underscore_casing_rox_your_sox_off!

  2. #2 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”.

    • #3 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%.

  3. #4 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.

    • #5 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.

  4. #6 by Hardboiled on May 20, 2011 - 3:56 am

    I’d switch to underscore, but I won’t put up with the ugliness and extra work.

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

    • #8 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.

  6. #9 by Galen Chock on November 25, 2011 - 4:46 am

    I use both camel case and underscores depending on what I am naming so I’m ambi-case.

  7. #10 by Jeremy Knight on March 1, 2012 - 6:39 pm

    I moved to camelCase awhile back and still find my self needing to convert from underscore to camelCase. I looked around for a web-based tool to make this easier. Didn’t find one so I made this:

    http://jeremy-knight.com/underscore2camel/

    Works pretty well for me so far.

    • #11 by Steven Jeuris on March 23, 2012 - 2:11 pm

      I demand one which does camel to underscores! :) P.s. It doesn’t work for e.g. ‘_private_var’. It turns it into ‘PrivateVar’.

      • #12 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…

    • #13 by dj on July 26, 2013 - 10:02 pm

      Maybe something like:

      sed -r ‘s/([[:alpha:]])_([[:alpha:]])/\1\u\2/gi’ inFile

  8. #14 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.
    Consider:
    a_function_with_a_very_long name_applied_to an argument_with_a_similarly_long_one
    vs
    a_function_with_a_very_long_name_applied_to an_argument_with_a_similarly_long_one
    vs
    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
    vs
    aFunctionWithAVeryLongNameAppliedTo anArgumentWithASimilarlyLongOne
    vs
    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
    vs
    g a
    vs
    h i j

    FF

    • #15 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”: http://whathecode.wordpress.com/2011/11/13/the-code-formatting-fallacy/

      • #16 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.

    • #17 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)
      vs
      a_function_with_a_very_long_name_applied_to(an_argument_with_a_similarly_long_one)
      vs
      a_function_with_a(very_long, name_applied_to_an_argument_with_a_similarly_long_one)

      aFunctionWithAVeryLong(nameAppliedTo, an, argumentWithASimilarlyLongOne)
      vs
      aFunctionWithAVeryLongNameAppliedTo(anArgumentWithASimilarlyLongOne)
      vs
      aFunctionWithA(veryLong, nameAppliedToAnArgumentWithASimilarlyLongOne)

  9. #18 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.

    TCP_IP_CurrentConnection

    or

    it_IsAn_ILLICIT_ButReadableIgloo.
    :)
    And I am a programmer, yes… :D

    • #19 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. :)

      • #20 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.

  10. #21 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.

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

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

    • #23 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.

      • #24 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.

    • #25 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.

  11. #26 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.

    http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

    • #27 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. :)

  12. #28 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 :)

  13. #29 by Wyrmwood on July 12, 2012 - 11:06 pm

    I honestly came here undecided. I’ve been doing development and maintenance a lot lately and at the moment, have code that uses both, depending on who wrote it or where it came from. That was clearly a poor choice, so I decided to make it all one way or the other. After reading this article, I must admit, correctness is enormously important for me. With multiple team members modifying the same code, updating the wrong logic could be detrimental. This is the kind of error that just blossoms in the amount of time it takes to track down and fix. Since we have both on our team (camel, underscore), I am proposing we choose one and stick with it. My argument will be for the camel, but I’ll be immensely happy with just one type :-)

  14. #30 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 :)

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

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

  16. #32 by Stubborn Mule on August 10, 2012 - 11:57 am

    I too came here somewhat undecided, but did so as an R programmer. I have been trying to decide whether to adopt an underscore or camel case approach rather than the more traditional period (or, as I would more naturally say, full stop):

    blahApprox
    blah_approx
    blah.approx

    When I program in python, I always use underscore, but with the idiomatic tradition of full stop in R, I cannot quite bring myself to switch. Yet.

  17. #33 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!

  18. #34 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.

  19. #35 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).

    • #36 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.

  20. #37 by Arun on February 15, 2013 - 7:22 am

    I never thought there is a war between underscore and camelcase till now. personally, I find underscores to be better than camel case for readability purpose.

  21. #38 by Miles Bader on February 15, 2013 - 9:49 am

    You forget another anti-CamelCase argument:

    “CamelCase is ugly, underscores are more elegant”

    That’s my personal opinion (I find CamelCase both much harder to read and uglier), but generally in any argument which has a significant religious component (which this one does), both sides will have that argument against the other.

  22. #39 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.

  23. #41 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.

  24. #43 by Walid Damouny on February 15, 2013 - 1:37 pm

    While I was still learning programming, I came across all these coding conventions and eventually picked and chose what I found worked for me. Underscores were easier to read for me because they allowed me to use regular words to convey semantics in a manner akin to writing regular text, like this comment. For some reason related to the way my brain processes typeface, camel case is very irritating to read. It feels like I’m stopped in my tracks to notice something new with a capital letter but then I realize that it’s just more of the same. By saying “irritating” I mean that it affects me emotionally and not just that I don’t want it.

    All said, I managed to live with all forms of notation and follow them in different projects because there usually is a lot of written code that I can’t modify.

    I’m still an underscore lover!

  25. #44 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.

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

      WeDoThisInPerl->all_the_time

    • #46 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()

  26. #47 by j2kun on February 15, 2013 - 5:59 pm

    Oh god, the spaces between the parens and the function arguments are even worse! How can I think either one looks appealing?

  27. #48 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?

  28. #50 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.

  29. #51 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!

  30. #52 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.

    • #53 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.

  31. #54 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..

  32. #55 by Geoffrey A. on May 29, 2013 - 8:30 pm

    IThinkThatYourVariableNamesAreTooLong.

  33. #56 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.

    • #57 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

  34. #58 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.

    • #59 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.

  35. #60 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!”

    • #61 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.

      • #62 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.

  36. #63 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.

    • #64 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…

    • #65 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.

  37. #66 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.

  38. #67 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.

    • #68 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.

      • #69 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”.

  39. #70 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.

  40. #71 by eche on December 24, 2013 - 1:54 pm

    It’s about taste, we should avoid being absolutist (and misreading science), even if “science” says 10% 20% whatever, it just doesn’t matter!, because using something that you don’t like is many many “%” worse.

  41. #72 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.

    • #73 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.

  42. #74 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!

    • #75 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.

  43. #76 by SamyR on March 24, 2014 - 10:31 pm

    camel casing is not elegant in any way. It looks ugly. There is a reason why it’s called camelCase. Camel looks ugly and so does camelCase words. (Sorry no offense meant to camels.)

  44. #77 by will on March 27, 2014 - 10:38 am

    i used to like camel case it has a couple flaws and i don’t like the underscore that starts the line
    1) that first lowercase makes you do dumb things like aMethodToFire instead of method_to_fire
    2) that first lowercase again when you have only one word like
    width are you going to write aWidth ?
    3) the under-score makes it easier to programmatically change the casing type

    _a_method_to_fire in fact i never use that except in a parameter and only when i need to a like width m(_width){ width = _width}

    the problem is this… you have… Class’s mMethods variables (parameters)

    so ive been trying to come up with my own style i have come to the conclusion that we are trying
    to make 4 different things distinct readable and identifiable programmatically

    so i think in actuality this is what ive come up with its about as simple and readable as i can get
    class’s all Capital, Methods the same but with underscores, variables lowercase

    MyClass.My_Method( T _my_parameter…optional..).my_variable interfaces Idisposable

    now i also wanted to distinguish between class objects and variables but that got difficult
    so i just settled on undecided there and leave them lower_case sides i have properties
    MyClass myobj = new MyClass();
    int width = 10;
    public int Width{ set{width = value;} get{return width;} } ahhhhhhhhh!!!!!!!!!!!!!!!!!!!!!!!!!!!
    AHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    im not happy with anything really im not i cant even figure out what looks good to me

  45. #78 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

  46. #80 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.

  47. #81 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:
    pass

    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: http://thomasmansencal.blogspot.fr/2014/02/the-camelcase-of-mister-underscore.html

    Cheers,

    Thomas

    • #82 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).

  48. #83 by romy on June 18, 2014 - 10:07 am

    As android dev its easy to decide: all xml stuff is with underscore, all java stuff is CamelCase. It works and you see evry time very easy, what is heappen und what use.

  49. #84 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:
    centerFrequency_hz
    symbolPeriod_usecs
    incidentAngle_rad

  50. #85 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.

  51. #86 by Ravi Dhoriya on September 10, 2014 - 1:33 pm

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

  52. #87 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.

    Regards,
    Marc

  53. #88 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 ;-)

    • #89 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

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

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: