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

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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

Answer 9

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

Answer 10

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. classes — class 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 methods — CamelCase::just_like_regular_methods();

Answer 11

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

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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

Answer 20

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.

Answer 21

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.

Answer 22

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.