Identifiers should be cased correctly (CA1709, Microsoft.Naming)

This rule validate the identifiers by the casing accuracy. Microsoft Spell Checker splits the identifier by its casing, for example, if the identifier “isLocked” is a parameter of a method, the Spell Checker will treat this identifier as two words: “is” and “locked”. If any of the part is incorrectly cased, this rule will generate warning.

I also blogged an article to list the naming convention of the different code parts. Generally, only private (instance or static) fields, local variables, method parameters, and lambda expression parameters should be using camel casing (that is, first letter must be lowercased for the first compound word, the remaining words are first letter uppercased), all other parts – namespaces, types, public (instance or static, non-ready-only or read-only) fields, methods, properties, events, generic type parameters (should begin with T), constants, and resource string keys, should be Pascal naming (that is, the first letter of each compound word should be uppercased). For this rule, a violation will be caused if any of the following is detected:

• The name of the identifier is not cased correctly. For example, a method parameter “enableDataBasePersistence”, will cause a violation because the word “DataBase” should be spell as “Database”.
• The name of the identifier contains a two-letter acronym and the second letter is lowercase. For example, the name “DbConnection” is causing this rule failed to validate because “DB” is an acronym but it should not be cased as “Db” (it is not an abbreviation), another example is “IO”, this is an acronym for “Input/Output” so that it should be cased as “IO” but not “Io”. Oppositely, “ID” is an abbreviation so that it should be cased as “Id” (Pascal) or “id” (camel). I will discuss acronyms and abbreviations in a detail in the coming article.
• The name of the identifier contains an acronym of tree or more uppercased letters. For example, “HTML” is an acronym (stands for Hypertext Markup Language) so that it should be cased as “Html” (Pascal) or “html” (camel), similarly, “URL” is also an acronym (standards for Uniform Resource Identifier) so that it should be cased as “Url” (Pascal) or “url” (camel).

To simplify this rule, to correctly case the name of the identifiers, you should:

• Do not treat some compound words as individuals, for example, “database”, “counterpart”, “multipart”, “hypertext”, “stopwatch” etc. they should be treated as one word so that do not uppercase the first letter of the second word of them.
• If the name of the identifier contains acronyms that have more than two letters, in Pascal naming, just capitalize the first letter of this word; in camel naming, do not capitalize any letter.
• If the name of the identifier contains acronyms that have just two letters, in Pascal naming, capitalize both of the two letters; in camel naming, do not capitalize any of the two letters.
• If the name of the identifier contains abbreviations, in Pascal naming, just capitalize the first letter; in camel naming, do not capital any of the letter in this word.

To help you understand the rule, I list some common used tokens, including their correct Pascal and camel casing terms.

* The Framework Class Library (FCL) is using Db against DB, System.Data namespace defines many types that uses Db, such as DbReader, DbConnection and DbTransaction, which is a historical bug but cannot be fixed because of its backward compatibility.

** The Framework Class Library (FCL) also contains a method FromArgb() defined on System.Drawing.Color type, which is also a bug. Because Argb can confuse the developers who are using this method by its name. Argb could be treated as argument b, or Alpha RGB or something else. Microsoft would have made this method name as FromAlphaRgb to make more sense. Microsoft would not fix this bug because its backward compatibility.

Please notice for the tokens “ID”, “DB”, and “OK”, they are very special and case these tokens as “ID”, “Db” and “OK” will cause violations. I will discuss this in later article.

Please do not suppress this rule in most of the cases. Only suppress it when the word represents a meaningful acronym – for example, a company name or a technology name. Of course, it is also safe to add your own acronyms and abbreviations to the code analysis dictionary, as I discussed in this article.

For more information, please see this MSDN link for CA1709.