|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Identifiers should be cased correctly
Breaking - when fired on assemblies, namespaces, types, members and parameters.
Non Breaking - when fired on generic type parameters.
Naming conventions provide a common look for libraries that target the common language runtime. This reduces the learning curve required for new software libraries, and increases customer confidence that the library was developed by someone with expertise in developing managed code.
By convention, parameter names use camel casing; namespace, type, and member names use Pascal casing. In a camel-cased name, the first letter is lowercase, and the first letter of any remaining words in the name is in uppercase. Examples of camel-cased names are "packetSniffer", "ioFile", and "fatalErrorCode". In a Pascal-cased name, the first letter is uppercase, and the first letter of any remaining words in the name is in uppercase. Examples of Pascal-cased names are "PacketSniffer", "IOFile", and "FatalErrorCode".
This rule splits the name into words based on the casing and checks any two-letter words against a list of common two-letter words, such as "In" or "My". If a match is not found, the word is assumed to be an acronym. In addition, this rule assumes it has found an acronym when the name contains either four uppercase letters in a row or three uppercase letters in a row at the end of the name.
By convention, two-letter acronyms use all uppercase letters, and acronyms of three or more characters use Pascal casing. The following examples conform to this naming convention: 'DB', 'CR', 'Cpa', and 'Ecma'. The following examples violate the convention: 'Io', 'XML', and 'DoD', and for non-parameter names, 'xp' and 'cpl'.
'ID' is special-cased to cause a violation of this rule. 'Id' is not an acronym but is an abbreviation for 'identification'. The abbreviation 'OK' is another special-case that will cause a violation of this rule. Okay should be abbreviated as 'Ok' to avoid violating this rule.
It is safe to suppress this warning if you have your own naming conventions, or if the identifier represents a proper name, for example, the name of a company or a technology.
You can also add specific terms, abbreviations, and acronyms that to a code analysis custom dictionary. Terms specified in the custom dictionary will not cause violations of this rule. For more information, see How to: Customize the Code Analysis Dictionary