Throughout the years, computer scientists have never been able to agree on one common way in which to express human-readable concepts (including word breaks for compound names such as "XML reader" or "input stream") in arenas in which normal rules of English, such as spaces, cannot apply. As a result, various languages have used different rules and formats to indicate where a logical word break should occur.
A variety of styles have emerged over the years, summarized here:
The Pascal language was the first to use this style of capitalization, hence its name. In a compound name (such as "input stream" or "base type"), capitalize the first letter of each word, then eliminate the space. Thus, "input stream" becomes "InputStream" and "base type" becomes "BaseType". Proponents of this style like the fact that each word is distinctly separated (the uppercase letter always signifies a new word), while detractors point out that acronyms become difficult to work with. "xml parser" becomes "XMLParser", and "HTTP IO Factory" becomes "HTTPIOFactory".
"Camel-casing," as its called, is the style used frequently in Java. Again, in a compound name, the first letter of each word is capitalized, except for the first word, which is left lowercase. This produces, for example, "baseType" and "inputStream". Acronyms become particularly difficult if they come as the first word and styles diverge. The general agreement seems to be to have the entire acronym lowercased, as in "xmlParser".
This style is distinctive, if a bit difficult to read. All letters of the word are uppercased (as if typing with the caps-lock key down), and spaces are again eliminated. While it becomes visually distinctive, all-caps identifiers tend to become hard to readfor example "BASETYPE" or "INPUTSTREAM". As a result, aside from die-hard COBOL programmers, all-caps casing tends to be used only sporadically within a modern language.
Also known as "C-casing," this style has recently fallen out of favor, particularly in C++ and Java programming circles. C-casing keeps all words in lowercase, using the underscore (_) to replace spaces. Proponents like this style because it makes the compound name look nearly identical to the English equivalent ("input_stream" or "base_type"); detractors claim the underscore is overused and abused in names ("prepare_to_accept_the_users_input"). Underscore-separation case doesn't show up in the .NET Framework directly, but will probably appear as legacy C and C++ applications are ported (or simply recompiled) for the .NET environment.
As with many things, no one style fits all, and the Microsoft naming conventions use the first three (particularly Pascal casing) throughout.
Capitalization rules can be mostly summarized as the following:
Any name which is visible to consumers of the assembly (that is, anything declared with an access specifier of "public" or "protected") should be Pascal-cased. This means class names, properties, methods, and events.
Names internal to the assembly can be pretty much anything the component developer wishes (subject to corporate standards, of course); however, the Microsoft convention appears to continue the use of Pascal-casing for methods, events and properties. Fields are camel-cased.
Symbolic constants (the value of pi, the HTTP response code for a "File Not Found" error, and so forth) should be written using all-caps.
Remember that other languages in .NET are not case-sensitive; never differentiate between two C# methods using only case. (On top of being not CLS-compliant, this is just bad form and confusing.)