Camel case names: How strict?

Question

What is the feeling on how strictly one should apply camel casing to variables.

I'm thinking specifically of variables like identifiers whose names will contain ID. Do you use thingID, or the more correct thingId? The second one always looks wrong to me.

Answer 1

You could maybe follow the guidelines that MS has written:

• When you use an abbreviation or acronym that is 2 characters long, put them all in caps
• When the acronym is longer then 2 char's, use a capital for the first character

When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.

Answer 2

Consistency is the name of the game - stick to one set of rules, but which one you pick I don't think is important.

Answer 3

If you use something like FXCop then ID will be flagged, and Id will be recommended. Because Id is an abbreviation not an acronym.

This article discusses why: http://weblogs.asp.net/AndrewSeven/archive/2004/08/12/213440.aspx

I stick with Id now, to keep FXCop happy…

Unless I'm already on a project that uses ID, in which case consistency is a better way to go.

Answer 4

I would consider ID a special case. Like RAM or CPU it is usually written in all caps even out of the camelcase notation and even if it isn't an acronym, so I think you should keep it all caps:

thingID
getRAMUsage
getCPUUsage

Or you could go write your variables with underscores ("_") instead. This avoids a whole set of ambiguities:

thing_ID
get_RAM_usage
get_CPU_usage

As Damien Conway suggests in Perl Best Practices, Chapter 3 ("Naming Conventions", the chapter is online on Google Books). It is a Perl-oriented book, but some guidelines hold for whatever your favorite language is, I'm using some of them in C++ programming.

Answer 5

I always apply it strictly, for consistencies sake, and for ease of reading. That way it is also possible automatically manipulate the names in a meaningful way.

To me thingID looks wrong, and getRAMUsage looks horrible.

Answer 6

You have two competing goals:

• You want to make it easy to read long names
• You want to make it easy to recognize acronyms

The first rule recognizes the fact that most identifiers in programs are more than one word and thisisseveralwords just takes too long to parse and it might be outright awkward as in "pimp" or "pImp", "childmolestring" vs. "childMoleString".

On the other hand, we are used to read RAM, CPU, ID, DB, IBM which would lead to IBMDB2DBConnector instead of IbmDb2DbConnector - both are ugly because we are not used to read characters put patterns. Our brains don't see I-B-M, they see >IBM< (as if that was a bitmap instead of three characters).

Notice that rule #2 is in fact a specialization of rule #1: the ultimate goal is to make the code readable. It's hard enough to understand an unknown algorithm if you're not ripped out of your concentration all the time by weird names.

My solution is to try to avoid acronyms to solve issue #2. So instead of "getRAM()" how about "getMemory()" or better "getFreeMemory()"? DB is short but it's really a database and with modern IDEs, that's just one Ctrl+Space.