Names of Classes, Structs, and Interfaces 

In general, type names should be noun phrases, where the noun is the entity represented by the type. For example, Button, Stack, and File each have names that identify the entity represented by the type. Choose names that identify the entity from the developer's perspective; names should reflect usage scenarios.

The following guidelines apply to selecting type names.

Do name classes, interfaces, and value types with nouns, noun phrases, or occasionally adjective phrases, using Pascal casing.

Do not give class names a prefix (such as the letter C).

Interfaces, which should begin with the letter I, are the exception to this rule.

Consider ending the name of derived classes with the name of the base class.

For example, Framework types that inherit from Stream end in Stream, and types that inherit from Exception end in Exception.

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 letter I prefix on the interface name.

For example, the Framework provides the IAsyncResult interface and the AsyncResult class.

Names of Generic Type Parameters

Generics are a major new feature of the .NET Framework version 2.0. The following guidelines cover selecting the correct names for generic type parameters.

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.

IDictionary is an example of an interface that follows this guideline.

Consider using the letter T as the type parameter name for types with one single-letter type parameter.

Do prefix descriptive type parameter names with the letter T.

Consider indicating constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to ISession may be called TSession.

Names of Common Types

The following guidelines provide naming conventions that help developers recognize the intended usage scenario for certain classes. Where the guideline refers to types that inherit from some other type, this applies to all inheritors, not just the types that directly inherit. For example, the guideline "Do add the suffix Exception to types that inherit from Exception." means that any type that has Exception in its inheritance hierarchy should have a name that ends in Exception.

Each of these guidelines also serves to reserve the specified suffix; unless your type meets the criteria established by the guideline, it should not use the suffix. For example, if your type does not directly or indirectly inherit from Exception, its name must not end in Exception.

Do add the suffix Attribute to custom attribute classes.

ObsoleteAttribute and AttributeUsageAttribute are type names that follow this guideline.

Do add the suffix EventHandler to names of types that are used in events (such as return types of a C# event).

AssemblyLoadEventHandler is a delegate name that follows this guideline.

Do add the suffix Callback to the name of a delegate that is not an event handler.

Do not add the suffix Delegate to a delegate.

Do add the suffix EventArgs to classes that extend System.EventArgs.

Do not derive from the System.Enum class; use the keyword supported by your language instead. For example, in C#, use the enum keyword.

Do add the suffix Exception to types that inherit from System.Exception.

Do add the suffix Dictionary to types that implement System.Collections.IDictionary or System.Collections.Generic.IDictionary<TKey, TValue>. Note that System.Collections.IDictionary is a specific type of collection, but this guideline takes precedence over the more general collections guideline below.

Do add the suffix Collection to types that implement System.Collections.IEnumerable, System.Collections.ICollection, System.Collections.IList, System.Collections.Generic.IEnumerable<T>, System.Collections.Generic.ICollection<T>, or System.Collections.Generic.IList<T>.

Do add the suffix Stream to types that inherit from System.IO.Stream.

Do add the suffix Permission to types that inherit from System.Security.CodeAccessPermission or implement System.Security.IPermission.

Names of Enumerations

Do not use a prefix on enumeration value names. For example, do not use a prefix such as ad for ADO enumerations, or rtf for rich text enumerations, and so on.

This also implies that you should not include the enumeration type name in the enumeration value names. The following code example demonstrates incorrectly naming an enumeration's values.

public  enum Teams
{
    TeamsAlpha,
    TeamsBeta,
    TeamsDelta
}

Do not use Enum as a suffix on enumeration types.

Do not add Flags as a suffix on the names of flags enumerations.

Do use a singular name for an enumeration, unless its values are bit fields.

Do use a plural name for enumerations with bit fields as values, also called flags enumerations.

Portions Copyright 2005 Microsoft Corporation. All rights reserved.

Portions Copyright Addison-Wesley Corporation. All rights reserved.

For more information on design guidelines, see the "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book by Krzysztof Cwalina and Brad Abrams, published by Addison-Wesley, 2005.

See Also

Other Resources

Design Guidelines for Developing Class Libraries
Guidelines for Names