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.

I'll break this down:

Why do programmers have annoyingly mixed case function names?

Firstly, because you can't have a function name with spaces. You need to either substitute underscores for spaces, or remove them entirely. Suppose you have a function that converts data of Format A to data of Format B. You can do this a few ways:

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


The first two may seem slightly more readable, but they aren't used much because underscores are a major pain to type. There's also an issue of where you put the underscores... is 'FormatA' one word? Standardizing things means you don't need to check your headers as often. The first two are also longer, and the more visual space you can conserve, the better.

The third one is, obviously, much harder to read. Mixed Case may be 'annoying', but it's much better than having to decipher all lower or upper case. The function name could be read as "Convert for Mat at of or Mat B". Which doesn't make any sense. And you probably didn't even notice that I threw the word 'dog' in there.

The fourth function, while slightly less readable than the first two, is much easier to type and has no standardization issues.



Why do programmers have long function names?

Sure, you COULD call the function 'CFA2FB'.. but that makes no sense. Even if you just simplify it to 'CvtFmtA2FmtB', there's a question of what kind of abbreviation standard you're using. Did you abbreviate 'Convert' to 'Cvt'? Or 'Cnvt'? Maybe 'Conv'? And someone else reading your code might thing 'Cvt' stood for 'Covet'. THAT also doesn't make any sense, but not everyone's as bright as you are. Grin. If the function is only used a few times in your program, you're better off leaving it unabbreviated so you don't have to check your headers every time you need to call it. If you call it something like CFA2FB, you'd need to add a comment along the lines of '// Convert the data (in format A) to format B.' anyway, so you wouldn't save time. (You do comment your code, right?)

If the function is called frequently, however, you're unlikely to see a fully descriptive function name, simply because the sheer number of times you have to type the thing mounts up. However, because it's used frequently, you shouldn't need to check headers, so you can call it whatever you want.


Nodeshell Rescue

No, *not* StUDlY caPS.

Rather, one way that programmers make identifiers out of multi-word phrases. To wit: Capitalize the first letter of each word, and stick the whole thing together. Also known by the more boring name of BiCapitalization.

For example:

XCoordinate
PersonnelRecord
ThisIsAVeryLongIdentiferIndeed


CrazyCaps got their start with early programming languages that accepted lower case letters in identifiers, but not underscores. The most well-known of these languages is probably Pascal (yes, every known extension to Pascal allows underscores. The Honeywell Pascal compiler I learned on didn't).

There are several possible reasons why some programmers still like to use CrazyCaps for identifers:
  • 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.

One method of writing multi-word identifier names in computer languages that tokenize on whitespace. For example, a variable called "my favorite variable" could be written

myFavoriteVariable (lower camel case)
MyFavoriteVariable (upper camel case)
my_favorite_variable (underscored)
my-favorite-variable (dashed)
MY_FAVORITE_VARIABLE (all caps)
myfvvbl (some people would actually use this one)

Much has been argued over whose style is better. C programs historically use underscored identifiers, while Java programs typically use lower camel case for identifiers and upper camel case for classnames. YACSFW (yet another coding style flamewar)

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

Log in or register to write something here or to contact authors.