Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

Edit

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

share|improve this question

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.

1  
They took my edit privileges! :cry! –  Manoj R Dec 17 '10 at 8:30
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

27 Answers 27

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:

aRatherLongSymbolName

or this:

a_rather_long_symbol_name

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):

isIllicitIgloo

I find this version a lot easier to read:

is_illicit_igloo

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.

share|improve this answer
24  
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
16  
I hate typing underscores. –  EpsilonVector Dec 18 '10 at 0:35
4  
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 =)

share|improve this answer
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

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. :)

share|improve this answer
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
1  
@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

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.

share|improve this answer

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."

share|improve this answer
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

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.

share|improve this answer
2  
+1 for making me discover glasses-mode! I just tested it on a code file that uses camelCase, and noticed how it immediately started looking better (assembly with loads of labels in camelCase). –  Gauthier Dec 17 '10 at 13:54

camelCase

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.

share|improve this answer

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
share|improve this answer
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

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 :)

share|improve this answer

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())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

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).

share|improve this answer

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

Like

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

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

share|improve this answer
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

Both!

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();
share|improve this answer
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

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.

share|improve this answer
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.

share|improve this answer

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:

i2c_BufferSend()

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.

share|improve this answer
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

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.

share|improve this answer
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.

Update

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).

Source

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.

share|improve this answer

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.

share|improve this answer

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:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

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

share|improve this answer
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

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.

share|improve this answer

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

  • ClassNamesArePascalCase
  • methodNamesAreCamalCase
  • variable_names_are_underscore
  • CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

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.

UPDATE:

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).

share|improve this answer

I think it's common style problem! If you're working with Wordpress! you should use underscore! if you're working with Kohana, you should use underscore, if you're working with Drupal, use underscore too! But if you worked with Zend, CakePHP,..u should use camelCase! So far it's just a convention to make a common style between its developer!

Also, if you're using underscore you have a benefit: easy to split it for auto loading/path! Example Axcoto_Log_History should be localte in Axcoto/Log/History!

share|improve this answer

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.

share|improve this answer

I used to use camel/pascalcase, but I found that underscore case is just easier to read.

share|improve this answer

Whatever you use, will be more readable than NAMES-IN-ALL-CAPS with DASHES-INSTEAD-OF-UNDERSCORES. Of course, most languages won't allow such a use of minus signs anyway.

edit: That's how it looks in the C**OL language, just in case you where wondering where I saw such ugly naming standards.

share|improve this answer

I use camelcase for classes and methods, underscore for vars and functions. It has worked pretty well for me, and others I work with.

share|improve this answer

In Erlang I use PascalCase for variables as they must start with an uppercase, and underscore for atoms/function names, which I think is more legible. Just to be consistent.

I have also seen Pascal_Case in variables which I think is he worst of both worlds.

share|improve this answer

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