| Do | Use PascalCasing for namespace, type, and member names consisting of multiple words. |
| Do | Use camelCasing for parameter names. |
| Do | Capitalize both characters of two-character acronyms except the first word of a camel-cased identifier. |
| Do | Capitalize only the first character of acronyms with three or more characters except the first word of a camel-cased identifier. |
| Do Not | Capitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier. |
| Do Not | Capitalize each word in so-called closed-form compound words. |
| Do Not | Assume that all programming languages are case sensitive. |
| Do | Choose easily readable identifier names |
| Do | Favor readability over brevity. |
| Do Not | Use underscores, hyphens, or any other non alphanumeric characters. |
| Do Not | Use Hungarian notation. |
| Avoid | Using identifiers that conflict with keywords of widely used programming languages. |
| Do Not | Use abbreviations or contractions as part of identifier names. |
| Do Not | Use any acronyms that are not widely accepted, and even if they are, only when necessary. |
| Do | Use semantically interesting names rather than language-specific keywords for type names. |
| Do | Use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type. |
| Do | Use a common name, such as value or item, rather than repeating the type name, in the rare cases when an identifier has no semantic meaning and the type of the parameter is not important. |
| Do | Use a name similar to the old API when creating new version of an existing API. |
| Do | Prefer adding a suffix rather than a prefix to indicate a new version of an existing API. |
| Consider | Using a brand new, but meaningful identifier, instead of adding a suffix or a prefix. |
| Do | Use a numeric suffix to indicate a new version of an existing API, if the existing name of the API is the only name that makes sense (i.e., it is an industry standard), and adding any meaningful suffix (or changing the name) is not an appropriate option. |
| Do Not | Use the “Ex” (or similar) suffix for an identifier to distinguish it from an earlier version of the same API. |
| Do | Use the “64” suffix when introducing versions of APIs that operate on a 64-bit integer (a long) instead of a 32-bit integer. |
| Do | Choose names for your assembly DLLs that suggest large chunks of functionality such as System.Data. |
| Consider | Naming DLLs according to the following pattern: <Company>.<Component>.dll |
| Do | Prefix namespace names with a company name to prevent namespaces from different companies from having the same name. |
| Do | Use stable, version-independent product name at the second level of a namespace name. |
| Do Not | Use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived. |
| Do | Use PascalCasing and separate namespace components with periods (e.g., Microsoft.Office.PowerPoint). |
| Consider | Using plural namespace names where appropriate. |
| Do Not | Use the same name for a namespace and a type in that namespace. |
| Do Not | Introduce generic type names such as Element, Node, Log, and Message. |
| Do Not | Give the same name to types in namespaces within a single application model. |
| Do Not | Give types names that would conflict with any type in the Core namespaces. |
| Do Not | Assign type names that would conflict with other types within a single technology. |
| Do Not | Introduce type name conflicts between types in technology namespaces and an application model namespace (unless the technology is not intended to be used with the application model). |
| Do | Name types with nouns, noun phrases, or, occasionally, adjective phrases, using PascalCasing. |
| Do Not | Give class names a prefix (e.g., “C”). |
| Consider | Ending the name of derived classes with the name of the base class. |
| Do | Prefix interface names with the letter I, to indicate that the type is an interface. |
| Do | Ensure that when defining a class – interface pair where the class is a standard implementation of the interface, the names differ only by the “I” prefix on the interface name. |
| Do | Name generic type parameters with descriptive names, unless a single-letter name is completely self-explanatory and a descriptive name would not add value. |
| Consider | Using T as the type parameter name for types with one single-letter type parameter. |
| Do | Prefix descriptive type parameter names with T. |
| Consider | Indicating constraints placed on a type parameter in the name of the parameter. |
| Do | Follow the guidelines described in Table 3-4 (page 58) when naming types derived from or implementing certain .Net Framework types. |
| Do | Use a singular type name for an enumeration, unless its values are bit fields. |
| Do | Use a plural type name for an enumeration with bit fields as values, also called flags enum. |
| Do Not | Use an “Enum” suffix in enum type names. |
| Do Not | Use “Flag” or “Flags” suffixes in enum type names. |
| Do Not | Use a prefix on enumeration value names (e.g., “ad” for ADO enums, “rtf” for rich text enums, etc). |
| Do | Give methods names that are verbs or verb phrases. |
| Do | Name properties using a noun, noun phrase, or adjective. |
| Do Not | Have properties that match the name of “Get” methods. |
| Do | Name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). |
| Consider | Giving a property the same name as its type. |
| Do | Name events with a verb or a verb phrase. |
| Do | Give events names with a concept of before and after, using the present and past tense. |
| Do Not | Use “Before” or “After” prefixes or postfixes to indicate pre and post events. |
| Do | Name event handlers (delegates used as types of events) with the “EventHandler” suffix. |
| Do | Use two parameters name sender and e in event handlers. |
| Do | Name event argument classes with the “EventArgs” suffix. |
| Do | Use PascalCasing in field names. |
| Do | Name fields with nouns or noun phrases. |
| Do Not | Use a prefix for field names, (e.g., “g_” or “s_”). |
| Do | Use camelCasing in parameter names. |
| Do | Use descriptive parameter names. |
| Do | Use PascalCasing in resource keys. |
| Do | Provide descriptive rather than short identifiers. |
| Do Not | Use language-specific keywords of the main CLR languages. |
| Do | Use only alphanumeric characters and underscores in naming resources. |
| Do | Use the dot separator to nest identifiers with a clear hierarchy. |
| Do | Use naming conventions for naming exception messages as indicated on page 65. |