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

closed as not constructive by ChrisF Dec 28 '11 at 0:56

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by yannis Jan 2 '15 at 5:02

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

  • 6
    "honestly the code is easier to read" Opinion or fact? – JD Isaacks Dec 17 '10 at 14:13
  • 9
    IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad. – dietbuddha Dec 18 '10 at 2:08
  • 7
    @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. :) – Steven Jeuris Feb 10 '11 at 1:11
  • @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". – Steven Jeuris Feb 10 '11 at 1:27
  • 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". – Christopher Mahan Aug 24 '11 at 19:51

22 Answers 22

up vote 84 down vote accepted

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.

  • 25
    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. – LearnCocos2D Dec 17 '10 at 9:38
  • 11
    For the first one, I actually found camelCase easier to read - though the latter is obviously different. – Phoshi Dec 17 '10 at 9:56
  • 19
    This indeed depends on what you're used to. I find camelCases easierToRead, and besides, they're shorter than equivalent underscore names. – Joonas Pulakka Dec 17 '10 at 12:17
  • 17
    I hate typing underscores. – EpsilonVector Dec 18 '10 at 0:35
  • 6
    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. – hlovdal Jan 21 '13 at 12:44

I think you should use naming convention adopted by your platform. underscore_case will look weird in C# code, as camelCase in Ruby =)

  • 23
    Consistency is a key. Whether you agree with the local convention or not you will make your own time easier (and everyone else's) by being consistent. (Unless the local convention is itself inconsistency.) Also, readability is mostly a false argument: read enough code any you'll discover there is little difference unless you decide it is unreadable. – Richard Dec 17 '10 at 10:43
  • 1
    Fully agree. I just think that it is better to use platform convention instead custom ones, because for example new guys in team will feel more comfortable with it. – Alexey Anufriyev Dec 17 '10 at 10:55
  • 2
    But woe to those of us that work in two platforms with two conventions, where some prefer on and some prefer the other! – Michael K Dec 17 '10 at 16:55
  • If platform has 2 conventions, I'd ask all team members to vote for convention they are comfortable with=) – Alexey Anufriyev Dec 18 '10 at 8:01

Honestly, it doesn't really matter as long as everyone on the team uses the same scheme. Chances are one or the other is more natural to you, though the real importance is readability of code in the long run and then it is crucial that everyone adheres to the same naming rules.

  • you are totaly right , however i'm trying to find out peoples opinion on witch would be better to use ( let's say for the whole team ) , and why ... while i understand that some people might be just used to some convention or others feal more natural with the other one . – poelinca Dec 17 '10 at 8:17

Based on a reply the reply of John Isaacks:

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

I decided to do some research, and found this paper. What does science have to say on the subject?

  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.

In my blog post on the subject I review the scientific paper, and make the following conclusion.

Only the slowness of camel case (2) is really relevant for programming, dismissing the other points as irrelevant due to modern IDEs and a majority of camelCase users in the study. The discussion (along with a poll) can be found on the blog post.

I'm curious how this article might change ones opinion. :)

  • 3
    Of course, you dismiss all of the other points because of your preference for underscores and the other points don't help your case... – Charles Boyung Aug 24 '11 at 18:32
  • 2
    @Charles: Yes and no, IMHO I do make good arguments why they are dismissable, and some of them are even discussed as problematic by the paper itself. A follow-up paper investigates some of the problems of this paper, and the results are pro-underscores. – Steven Jeuris Aug 24 '11 at 19:36

Copy the Smartest Guys

In the case of programming languages, copy the style of the developer of the language.

For example I code C exactly as is done in K&R.

Then when anybody tries to start a boring coding style conversation, I can tell them "bring that up with Dennis Ritche and let me know what he says."

  • 12
    The original is not always the best. There are many bad practices in the the K&R gospel book on C. Before this starts a flame war... read some of the MISRA recommendations. – quickly_now Dec 17 '10 at 12:16
  • 10
    Don't forget, K&R was written when there no GUI-IDEs. Most work was done on 80x25 character terminals, so screen space was at a premium, doing if (...) { saved a line! These days, there's more screen space - would K&R be different if written today with hi-res GUI IDEs and multiple monitor set ups? – Skizz Dec 17 '10 at 13:26
  • 3
    Yeah, but when someone says they code C like K&R, they get props for being old-school. – Christopher Mahan Dec 17 '10 at 20:13
  • 3
    @quickly_now, bring that up with Dennis Ritchie and let me know what he says! – Mark Harrison Dec 18 '10 at 12:19
  • I adopt a lot of formatting from MS: _internalToClassOnly, accessibleByGetter, PublicVariable. – IAbstract Jan 6 '11 at 22:51

In general, I prefer camelCase. However, that is because most of my career, I've working in languages and environments where the style guides normally recommend camelCase. (Java, ECMAScript, C++). You, being a PHP person, are likely to have the opposite preference.

That said, when you go beyond threeOrFourWords, or if you use initialisms likeXmlForExample, it stops being so readable.

That is why emacs gives us glasses-mode.


This is one of the few places I will always choose 'type-ability' over readability. CamelCase is just easier to type, and being nicer to my fingers wins out over a slight readability gain for me.

assuming of course that the project does not build on an existing codebase with a different standard.

  • I don't agree with that, you write code only once, but you have to read it multiple times afterward – Roman Pekar Sep 16 '14 at 15:21

It is an interesting question, I have thought on this many times. But there is no a definite answer, I think.

Following the "cultural" conventions it a good choice. "Cultural" in this case means conventions set up in the team/company and they basically carry the language/platform conventions as well. It helps others to read/use your code easily and doesn't require additional efforts and time to get into the way of understanding your code.

Sometimes it is interesting to break accepted notations. One of my small projects (on Python) I used underscored_names for utility functions/"protected" methods, and Java-style methodNames for methods. My team was happy with it :)

Depends on the programming language.

I consider using the case in the same boat of whether or not to use Hungarian notation:

  • Python: underscore_case, no Hungarian notation
  • C++: camelCase, Hungarian notation
  • 8
    @Kevin Cantu: Actually the name Javascript is in PascalCase rather than camelCase... – Guffa Dec 17 '10 at 8:53
  • 1
    @Guffa: touché! – Kevin Cantu Dec 17 '10 at 8:55
  • 2
    @Kevin Cantu: on JavaScript: XMLHttpRequest <-- I hate this name with a passion. – Thanatos Jan 7 '11 at 7:01
  • 1
    hypotheticalReasonsToNukeRedmond.push(XMLHttpRequest) – Kevin Cantu Jan 7 '11 at 8:52
  • 4
    @Lionel: Actually Hungarian notation is almost never used in C++, since C++ already checks your types. It's more of a historical artifact than anything else. – In silico Aug 24 '11 at 20:43


I do a lot of development in CakePHP, and I use either CamelCase or $underscored_vars, in the following fashion (even outside CakePHP Projects):

  1. filenames/lowercased_underscored.php Typical, but worth mentioning.
  2. classesclass CamelCase extends ParentObject. Note that, when using CamelCase, the initial character is not lowercase. I find camelCase to look really weird.
  3. variables$are_variables_underscored === TRUE;
  4. variables that hold instances$CamelCase = new CamelCase();
  5. array keys$collection['underscored_keys'];
  6. constants — I think everyone can agree that constants should be ALL_CAPS_AND_UNDERSCORED.
  7. methods$CamelCase->foo_method_underscored();
  8. static methodsCamelCase::just_like_regular_methods();
  • 3
    have to agree with you, having the first character be lower case drives me crazy! I hate camelCase with a passion. – HLGEM Jan 6 '11 at 22:00
  • In Java where names are typically camelCased the class names actually start with a Capital letter. This is to distinguish them from method names. – James P. May 2 '11 at 0:22

I personally prefer underscore_case because I find it more readable, but agree with the other answerers who point out that consistency with the existing codebase is much more important.

However, I have a counterexample for those who say "follow the convention of your language and its libraries".

In the past we wrote C code on Windows using underscore_case, and called PascalCase Win32 functions:

if (one_of_our_conditions_is_true())

The visual distinction between our function names and Microsoft's function names was a help rather than a hindrance, as it clearly showed when the code was going into "system land".

In addition, I was able to change my editor's syntax highlighting rules to display them in different colours, which gave further visual clues when trying to understand unfamiliar sections of code (or even my own).

I really like Dylan's just-normal-dashes-as-they-are-easy-to-type-and-easy-to-read.


result-code := write-buffer(file-stream, some-string)

But I guess as this language is fairly obscure, this is kind of off-topic... :(

  • 3
    I am also tired to pressing shift for typing underscores. – Gauthier Dec 17 '10 at 14:02
  • 8
    This is usally not possible for variable names, since "-" usually means minus. – Eric Wilson Dec 17 '10 at 18:24

I was taught to use camelCase at university. I've used a few different conventions over the last few years but prefer camelCase over anything else. I think I remember reading somewhere that camelCase is actually the easiest to read and understand.

  • 4
    well it's not easyer becouse you read somewhere , it's easyer becouse it was the first one you worked with and mainly becouse you are more used to it , for example i'm more comfortable with underscore_case. – poelinca Dec 17 '10 at 8:42
  • 1
    as in i've read that a study was done and found it to be better.. – Ross Dec 18 '10 at 10:33

As most people have mentioned - Use the existing standard. If it's a new project, use the standard for the language and frameworks you will be using.

And don't get confused, this is not about readability (which is subjective), it's about being consistent and professional. Anyone who has worked in a codebase with numerous 'standards' going on will understand.

I use a mix sometimes: module_FunctionName. All (non-static) functions in my modules start with a module abbreviation.

For example a function for sending a buffer's content on the I2C bus:


The alternative i2c_buffer_send does not show a big enough separation between prefix and function name. i2cBufferSend mixes in the prefix too much (there are quite a number of I2C functions in this module).

i2c_Buffer_send might have been an alternative, though.

My answer being that you adapt to what works best for your project (your language, your SW architecture, ...), and I wanted to point out that mixing these styles might be useful.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

  • 1
    +1 for the last 2 lines , however i do not recomend you combine naming conventions , you should stick with one or the other . – poelinca Dec 17 '10 at 9:33
  • As long as the convention is well defined (prefix + underscore + PascalCase)... – Gauthier Dec 17 '10 at 9:35
  • I like to use underscores to separate parts of a name which have semantically-disjoint purposes, especially if commonality on either half may be significant. For example, the routines Motor1_Start(), Motor2_Start(), Motor1_Stop() and Motor2_Stop() have a relationship that might be less clear without the underscores. – supercat Aug 13 '12 at 18:18

Personally, I prefer camelCase, but in some fonts I think underscores are easier to read.

I would suggest that if you need to use prefixes to differentiate sets of variables, you should use a language that lets you make namespaces or objects or something to hold that information.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Likewise, if you need to differentiate types, why not use a language that allows them?

var intThingy = 7; // :(

int thingy = 7;    // :)

Once you have that straight, and you're not just using the name as meta-data, then you won't have enough long names that it matters very much whether you prefer that extra keypress or not.

  • 1
    One of the reasons for using camelCase or underscore_case is so that I don't need to find the objects definition to discern what it is. – Joshua Shane Liberman Dec 17 '10 at 13:54

At first, I agree with dafmetal. It is of the upmost importance, that you do not mix different programming styles. Doing this in one and the same file is the worst you can do IMHO. Across different files, it is distracting, but not fatal.

The next thing you have to do, is at naming rules that are popular for the language that you are writing in. My C++ code for instnace, will look different than something for Python obviously (PEP8 is a nice guide here)

You can also use different naming conventions to refer to different things, as much as you probably use UPPER_CASE for constants (this only applies to certain languages of course), you can use this_style for local variable names, whereas you use camelCase for instance/member variables. This may not be needed when you have things such as self or this however.


Let's take a case where you have the platform Foo witch doesn't recomend 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.

There are no advantages for one over the other really. This matter is very subjective and once agreed upon, it will not make a difference. There are always these religuous wars about these small things. But once you have gotten adjusted to either, the discussions seems to be entirely superfluous.

To quote Alex Martelli on a very similar matter:

Sure, I do get weary, in Ruby, of typing the silly "end" at the end of each block (rather than just unindenting) -- but then I do get to avoid typing the equally-silly ':' which Python requires at the start of each block, so that's almost a wash:-). Other syntax differences such as '@foo' versus 'self.foo', or the higher significance of case in Ruby vs Python, are really just about as irrelevant to me.

Others no doubt base their choice of programming languages on just such issues, and they generate the hottest debates -- but to me that's just an example of one of Parkinson's Laws in action (the amount on debate on an issue is inversely proportional to the issue's actual importance).


If you are the team leader, you just go with one. Since one doesn't have any advantages over the other, you can just throw dice or pick what you like more.

I read several years ago that programmers who don't speak English as a first language tend to find underscore case easier to understand that camel case- but I can't find the reference, and I have no idea whether it's true.

For programming languages I've used, like Java, Python, C++, I've adopted a clear format:

  • ClassNamesArePascalCase
  • methodNamesAreCamalCase
  • variable_names_are_underscore

This allows me to immediately discern what I'm dealing with. I have found that to be useful to maintain for myself, and it should be easy to follow for someone else reading the code. I think as others mentioned consistency is most important. So I find my format to be simple enough to maintain, while providing clear distinctions between types of names. I could imagine interface_Names_Are_Like_This and Abstract_Classes_Are_Like_This as possible extensions, but seem to be more complicated to follow and maybe not as useful a distinction to make.

I've also found it useful to be strict and name things in PascalCase such as an HTML parser as HtmlParser instead of HTMLParser or HTMLparser. Because I believe it's easier to remember the strict rule and keeps the word boundaries clearer (unfortunately it requires misspelling things like HTML or SQL). Similarly with camelCase, htmlParserMethod instead of HTMLParserMethod or HTMLparserMethod.


I've since found use in expanding these rules to include private variables. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

In Java, this means that private fields are by definition in a different namespace than local variables, which means you can skip the this. on private fields. Other formats I've seen prefix with "m", but those formats also use camelCase for the variable names. This also allows me to make a distinction between fields that should only be accessed internally by the class (and making it super clear when it's happening outside of the class object._field_x stands out).

If it were down to me, I wouldn't enforce or hint at the use of any particular style because, as programmers, we whould be able to read a symbol IfItIsInCamelCase or in_underscore_space or even in_SomeOtherStyle and understand what it means. Having to spend a tiny amount of time parsing the symbol is no great overhead in the big scheme of things.

Now, the main argument for a convention I guess is that you know upfront what the format of a function/variable name is and don't need to look it up - is it LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Now, I would counter that argument by saying "Get an IDE that supports intellisense style auto completion!" (not always possible though).

In the end though, it doesn't really matter what style you use beacuse the compiler / interpreter doesn't really care. What is important is that the name is useful:


Three different styles, but you know exactly what each one does.

  • 1
    I beg to differ, the appearance of source is important. See "The pragmatic programmer"'s broken windows theory. Varying naming convention makes the appearance worse. pragprog.com/the-pragmatic-programmer/extracts/software-entropy – Gauthier Dec 17 '10 at 13:59
  • 1
    @Gauthier: Although I agree with the 'broken window' idea, I don't think capitalisation of symbols constitutes a 'broken window'. Haphazardly laid out code certainly is, and my current project certainly has a lot of that which I try to tidy up whenever I can. – Skizz Dec 17 '10 at 15:54
  • I agree. I can read all three equally well. It doesn't matter. I just use whatever the file is using, then whatever the language proposes (python) and then whatever I feel the project will be best served by. (I used to program in gwbasic, and it was all caps--the good old days!) – Christopher Mahan Dec 17 '10 at 20:17

May seem silly, but I don't like underscores because the underscore is thin, and hides in multiple line text and I miss it. Also, in some (many) text editors and/or dev environments, when you double click on a token name to highlight it so as to copy or drag and drop it, the system will not highlight the entire token, it only highlights one portion of the token, between adjacent underscores. That drives me nuts.

I tend to prefer camelCase for the silly reason that I do most of my development in Eclipse (For Java, PHP and JavaScript), and when I Ctrl+ or Ctrl+ through words, it actually stops at the camelCase boundaries.

I.e.: myIntVariable would be treated by Eclipse as 3 words when Ctrl+← →'ing through it.

I know it's a weird quirk, but I find myself preferring being able to edit the middle words in a camelCase name.

Not the answer you're looking for? Browse other questions tagged or ask your own question.