CamelCase

CamelCase (or CamelCaps) is a Capitalisation standard used for variable, type and function names in many computer programming languages. It is neither lower case or UPPER CASE. Some call this CrazyCaps.

Take a phrase, capitalise the first letter of each word, and remove the spaces between words. No underscores are used. It is so called because the profile resembles the humpy outline of a camel. If you have ever seen a variable called something like FooLoopCounter or a function called something like InitSomeGlobalFish, that's CamelCaps.

The Java programming language has an officially approved style for member function names that uses a variation on CamelCaps - every word except the first is capitalised. For instance a method could be called getSomeValue(). In C# style, this convention is used only for variable names.

You might think that CamelCaps is very straightforward, but there is room for error when compound words, abbreviations and acronyms enter the picture. English grammar is not always clear about these. I'll give some examples:

Compound words: PassWord or WheelBarrow are incorrect, as both of these are normally written as one word, even if they are derived from two words each. There will borderline cases, as two words used together will over time form a new compound word. For instance Timetable was originally a table of times, then a Time table.

Abbreviations: Only the first letter is capitalised, for e.g. Id is short for Identity or Identifier and thus the second letter is not capitalised.

Acronyms are formed from the first letter of each word, and thus all of these letters can be capitalised. For instance, if your program has code to deal with Point Of Sale terminals, you will most likely shorten this to Pos, but the correct capitalisation is POS, as it is derived from three words, e.g. as in getPOSId();

However some standards differ from this: e.g. the Microsoft C# style guide specifies that with acronyms of 3 or more characters, only the first is capitalised.

• Convert_Format_A_To_Format_B(A, B);
• convert_format_a_to_format_b(A, B);
• convertformatdogatoformatb(A, B);
• ConvertFormatAToFormatB(A, B);

• Pascal is case-insensitive, and the consequences of getting the capitalization wrong later are far less than in case-sensitive languages (such as C or C++, where you rarely see the things).
• The only company to make any amount of money selling Pascal compilers, Borland, has perpetuated the notion by eschewing underscores in the libraries accompanying its compilers.
• They might think that underscores are icky, especially for very, very long indentifiers.

Interestingly, the C world tends to have functions named convert_format_a_to_format_b() (underscores not BiCapitalisation, and lowercase letters preferred). C++ and Java weenies follow the more "object oriented" style convertFormatAToFormatB(). I think Azure Monk is wrong as regards the source: it's not because of convenience (or efficiency in typing -- C/UN*X weenies are big fans of both), it's because of history.

Standard Pascal didn't support the use of underscores in its standard character table; thus, the C style couldn't exist in Pascal. Presumably this further influenced C weenies to use underscores just because they could. Similarly, SmallTalk has a "←" character (used for assignment) where the underscore "_" should live in its character set, so underscores couldn't be used in method names there either.

And SmallTalk is pretty much the parent of modern object oriented languages. Presumably mixedCaseNames (as opposed to underscore_separated_names) are more a forgotten legacy of SmallTalk than some carefully-conceived ergonomic device.

Here's a cute little pseudo-standard that I use:

Variable names, or names of structs, classes, etc. have names like KleenexBox (for the struct) and kleenexBox (for the variable), since those things are like a single word. Functions, however, are more like a sentence, so separate parts are separated with underscores. That way, you can have a function name like kleenexBox_empty(KleenexBox *), it makes it clear that this is a function which empties a thing of type KleenexBox, as opposed to a function that puts a kleenex in a box and empties it, or a variable which represents an object: KleenexBoxEmpty.

Also note that programmers tend to start function and variable with lowercase letters, names of types of things (structs and classes) with uppercase letters, and constants with all uppercase letters. The Ruby language actually enforces this practice. While I was hacking through the Wolfenstein 3D source code, however, I found a ton of variable names that seemed to have been capitalized with no rhyme or reason. That's old C code for you. The APCS AP test does that, too (airplane::GetRows), but I probably shouldn't expect too much from them. I could go on for a looong time about the goofiness of the APCS course...

A special form of mixed-case identifiers widely used mainly in Java circles, so named because they look like this:

camelCaseIdentifier

The first word of a multi-word identifier is in lower case (the head of the "camel"), while subsequent words are capitalized (the "humps" of the "camel"). This is generally used for method names in classes, and sometimes for variable names as well. For class names, the convention is the same, except that the first letter of the class name is capitalized as well (e.g. CamelCaseClassName, cf. BiCapitalization, CamelCaps). This case convention is enshrined in the Sun Java Coding Conventions, and is used throughout the standard Java class library, so people programming in Java have come to use these conventions as well, just as the use of Hungarian notation in the Windows API has influenced code written on that platform.

Frankly, I'd prefer to use underscores for multiple-word identifiers, to allow Ctrl-arrow keys move from word to word in the name while using Emacs. Now, ariels informs me that Emacs has c-forward-into-nomenclature (and an analogous -backwards-), to forward into camelCase identifiers, but that still doesn't fix what IMHO is a more fundamental flaw with camelCase: it hurts the eyes.

The Java Coding Conventions document that describes camel case:

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367