Naming conventions: camelCase versus underscore_case ? what are your thoughts about it?

  • I've been using underscore_case for about 2 years and I recently switched to camelCase because of the new job (been using the later one for about 2 months and I still think underscore_case is better suited for large projects where there are alot of programmers involved, mainly because the code is easier to read).

    Now everybody at work uses camelCase because (so they say) the code looks more elegant .

    What are you're thoughts about camelCase or underscore_case

    p.s. please excuse my bad english


    Some update first:

    • platform used is PHP (but I'm not expecting strict PHP platform related answers , anybody can share their thoughts on which would be the best to use , that's why I came here in the first place)

    • I use camelCase just as everibody else in the team (just as most of you recomend)

    • we use Zend Framework which also recommends camelCase

    Some examples (related to PHP) :

    • Codeigniter framework recommends underscore_case , and honestly the code is easier to read .

    • ZF recomends camelCase and I'm not the only one who thinks ZF code is a tad harder to follow through.

    So my question would be rephrased:

    Let's take a case where you have the platform Foo which doesn't recommend any naming conventions and it's the team leader's choice to pick one. You are that team leader, why would you pick camelCase or why underscore_case?

    p.s. thanks everybody for the prompt answers so far

    "honestly the code is easier to read" Opinion or fact?

    IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad.

    @dietbuddha: I just read 'but_i_think_mixing_them_is_pretty_bad' a lot faster than 'IThinkTheyAreBothAboutTheSame'. I'm pretty sure that can be proven scientifically. :)

    @John Isaacks: I'm sad to report (as a undercase proponent), that one study concluded that _"camel casing leads to higher accuracy among all subjects regardless of training"_.

    IWonderWhetherReadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference. InTheEnd,IFindThatNeitherIsVeryGoodAtBeingEasyToRead. It_screws_horribly_with_line_length_and_makes_even_the_simplest_thing_complicated. I_wonder_whether_there_would_be_language_support_in_the_future_for_quoted_variable_names. "This would make a lot more sense in my opinion than either camelCase or underscore_separators".

    I hate you SHIFT and your stupid underscores/capitals. Why can't they just make the language parser smarter so you can use spaces or some other *easy-to-type* char? (hint-hint)

    Coming rather late to this discussion: camelCase is fine in languages which distinguish between upper and lower case, but has some pitfalls where there is no case sensitivity. Somewhat related:

    @ChristopherMahan `>> set to-word {My Variable} 5 == 5 >> print get to-word {My Variable} 5` - it's viewed as a stupid trick that shouldn't be done, though. ;)

  • I agree that it depends on the language you're using to some extent; code tends to look neater when your symbol names follow the same formatting regimen as the language's built-ins and stock libraries.

    But where there's a choice, I prefer underscores to camel case, for one simple reason: I find that style easier to read. Here's an example: which do you find more readable? This:


    or this:


    I find the underscore version much easier to read. My brain can ignore the underscores much more easily than it can detect the lowercase/uppercase boundaries in camel case, especially where the boundaries are between glyphs that look similar to other glyphs of the opposite case, or numerals (I/l, O/0, t/I, etc). For example, this boolean variable stores a value indicating whether or not an Igloo has been built with proper planning permission (undoubtedly a common use case for us all):


    I find this version a lot easier to read:


    Perhaps even worse than a hard-to-read symbol name is an easy-to-misread symbol name. Good symbol names are self-documenting, which to me means that you should be able to read them and understand their meaning at a glance. (I'm sure we all read code print-outs in bed for pleasure, but occasionally we grok in haste, too.) I often find with camel case symbol names that it's easy to mis-read them and get the wrong impression of a symbol's semantics.

    I agree. The underscore names tend to be longer, but more readable by far.

    One issue with underscores: usability. For most (european) keyboards, typing the underscore sign requires holding down the SHIFT key. You need to do that for camelCase as well, but I can comfortably hold down SHIFT with the pinky and type any letter - but since the underscore key is right next to the SHIFT key, pressing both at the same time is rather awkward and interrupts the flow of typing.

    For the first one, I actually found camelCase easier to read - though the latter is obviously different.

    This indeed depends on what you're used to. I find camelCases easierToRead, and besides, they're shorter than equivalent underscore names.

    @GamingHorror yeah but to be fair, european keyboards are in general awful for programming.. When in Swedish mode, I have to press alt-gr-7 for {, and a close tag in html has the same issue as the underscore, it's right next to the shift key. I'd say typing underscore is one of my lesser problems with european programming. (That said, my answer to the question would be to use whatever is standard practice in the language being used)

    int red = 5; int apple = 4; int red_apple = red-apple; UGLY.

    I *hate* typing underscores.

    @GamingHorror: I recommend every programmer to program in standard qwerty. (blind typing with all 10 fingers I might add!) It gives you an amazing efficiency boost.

    iCanReadCamelCaseAllDayBeenUsingItForMoreThanTwoYearsActuallyReadSomethingAboutThisInSpeedReadingInThatTheHumanEyeHasItEasierToReadTextThatHasIrregularSizingButNoIdeaHowItComparesWithUnderscoring (if you paused while reading that then you can consider as being used to another convention). P.S: Is iPhone and iPad camelCase-inspired?

    @LearnCocos2D: I don't know about your keyboard, but mine has two shift keys and you usually use the one "on the other side" ;)

    The "usability" point is irrelevant for this. Code is typically written just once by one person, but let's say in the order of 1-10 times accounting for some editing and potential pair programming. But code is typically read dozen/hundreds/thousands of times by one or potentially many people. Thus making code easy to read is several magnitudes more important than having code easy to write.

    `aRatherLongSymbolName` is a code smell in its own right. Using underscores as a remedy for its unreadability doesn't address the real issue here. A variable name should consist of 1 or 2 words; if there's 3 words, it's already something worth a second thought.

    @KonradMorawski - Opting for shorter names where possible can be good, but long variable names are not a bad thing by themselves. Self documenting code supports the notion that long names can sometimes be better for readability. See link (they use `numberOfWordsInThisArticle` as an example for a variable).

    @diegoreymendez I believe in well designed code it should be obvious that the number of words refers to "this" article (not some other one), and that it refers to an article. Once you have an `Article` class, the number of **whose** words would you expect to be stored in `wordCount`? That's self-docummenting enough, at least in OOP languages. I think Wiki goes out of its way to stress a point, but it's not really a good guide to be taken literally. Also the longer the name, the harder it gets to remember it (and to search for it for example). A matter of taste, maybe - well, this is mine :)

    @KonradMorawski - There are cases in which shortening the name is a possibility. However there are other cases in which it's not. For instance if `wordCount()` was a very expensive method to call each time, you'd be better off having a local variable such that `articleWordCount = article.wordCount()`. Obviously picking short names is preferred, but not shorter than what you need to properly convey the variable's meaning.

    @diegoreymendez fair enough, but that's still 3 words as opposed to 6 :)

    @LearnCocos2D, but code maintenance usually cost more time than code creation.

    @LearnCocos2D, learn to type by 10 fingers, like me.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM