.Net Framework Design Guidelines

Naming Guidelines

DoUse PascalCasing for namespace, type, and member names consisting of multiple words.
DoUse camelCasing for parameter names.
DoCapitalize both characters of two-character acronyms except the first word of a camel-cased identifier.
DoCapitalize only the first character of acronyms with three or more characters except the first word of a camel-cased identifier.
Do NotCapitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier.
Do NotCapitalize each word in so-called closed-form compound words.
Do NotAssume that all programming languages are case sensitive.
DoChoose easily readable identifier names
DoFavor readability over brevity.
Do NotUse underscores, hyphens, or any other non alphanumeric characters.
Do NotUse Hungarian notation.
AvoidUsing identifiers that conflict with keywords of widely used programming languages.
Do NotUse abbreviations or contractions as part of identifier names.
Do NotUse any acronyms that are not widely accepted, and even if they are, only when necessary.
DoUse semantically interesting names rather than language-specific keywords for type names.
DoUse 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.
DoUse 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.
DoUse a name similar to the old API when creating new version of an existing API.
DoPrefer adding a suffix rather than a prefix to indicate a new version of an existing API.
ConsiderUsing a brand new, but meaningful identifier, instead of adding a suffix or a prefix.
DoUse 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 NotUse the “Ex” (or similar) suffix for an identifier to distinguish it from an earlier version of the same API.
DoUse the “64” suffix when introducing versions of APIs that operate on a 64-bit integer (a long) instead of a 32-bit integer.
DoChoose names for your assembly DLLs that suggest large chunks of functionality such as System.Data.
ConsiderNaming DLLs according to the following pattern: <Company>.<Component>.dll
DoPrefix namespace names with a company name to prevent namespaces from different companies from having the same name.
DoUse stable, version-independent product name at the second level of a namespace name.
Do NotUse organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.
DoUse PascalCasing and separate namespace components with periods (e.g., Microsoft.Office.PowerPoint).
ConsiderUsing plural namespace names where appropriate.
Do NotUse the same name for a namespace and a type in that namespace.
Do NotIntroduce generic type names such as Element, Node, Log, and Message.
Do NotGive the same name to types in namespaces within a single application model.
Do NotGive types names that would conflict with any type in the Core namespaces.
Do NotAssign type names that would conflict with other types within a single technology.
Do NotIntroduce 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).
DoName types with nouns, noun phrases, or, occasionally, adjective phrases, using PascalCasing.
Do NotGive class names a prefix (e.g., “C”).
ConsiderEnding the name of derived classes with the name of the base class.
DoPrefix interface names with the letter I, to indicate that the type is an interface.
DoEnsure 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.
DoName generic type parameters with descriptive names, unless a single-letter name is completely self-explanatory and a descriptive name would not add value.
ConsiderUsing T as the type parameter name for types with one single-letter type parameter.
DoPrefix descriptive type parameter names with T.
ConsiderIndicating constraints placed on a type parameter in the name of the parameter.
DoFollow the guidelines described in Table 3-4 (page 58) when naming types derived from or implementing certain .Net Framework types.
DoUse a singular type name for an enumeration, unless its values are bit fields.
DoUse a plural type name for an enumeration with bit fields as values, also called flags enum.
Do NotUse an “Enum” suffix in enum type names.
Do NotUse “Flag” or “Flags” suffixes in enum type names.
Do NotUse a prefix on enumeration value names (e.g., “ad” for ADO enums, “rtf” for rich text enums, etc).
DoGive methods names that are verbs or verb phrases.
DoName properties using a noun, noun phrase, or adjective.
Do NotHave properties that match the name of “Get” methods.
DoName Boolean properties with an affirmative phrase (CanSeek instead of CantSeek).
ConsiderGiving a property the same name as its type.
DoName events with a verb or a verb phrase.
DoGive events names with a concept of before and after, using the present and past tense.
Do NotUse “Before” or “After” prefixes or postfixes to indicate pre and post events.
DoName event handlers (delegates used as types of events) with the “EventHandler” suffix.
DoUse two parameters name sender and e in event handlers.
DoName event argument classes with the “EventArgs” suffix.
DoUse PascalCasing in field names.
DoName fields with nouns or noun phrases.
Do NotUse a prefix for field names, (e.g., “g_” or “s_”).
DoUse camelCasing in parameter names.
DoUse descriptive parameter names.
DoUse PascalCasing in resource keys.
DoProvide descriptive rather than short identifiers.
Do NotUse language-specific keywords of the main CLR languages.
DoUse only alphanumeric characters and underscores in naming resources.
DoUse the dot separator to nest identifiers with a clear hierarchy.
DoUse naming conventions for naming exception messages as indicated on page 65.