Naming Guidelines

Use US English (AV1701)

All identifiers (such as types, type members, parameters and variables) should be named using words from the American English language.

• Choose easily readable, preferably grammatically correct names. For example, HorizontalAlignment is more readable than AlignmentHorizontal.
• Favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Use proper casing for language elements (AV1702)

Language element	Casing	Example
Namespace	Pascal	System.Drawing
Type parameter	Pascal	TView
Interface	Pascal	IBusinessService
Class, struct	Pascal	AppDomain
Enum	Pascal	ErrorLevel
Enum member	Pascal	FatalError
Resource key	Pascal	SaveButtonTooltipText
Constant field	Pascal	MaximumItems
Private static readonly field	Pascal	RedValue
Private field	Camel	listItem
Non-private field	Pascal	MainPanel
Property	Pascal	BackColor
Event	Pascal	Click
Method	Pascal	ToString
Local function	Pascal	FormatText
Parameter	Camel	typeName
Tuple element names	Pascal	(string First, string Last) name = ("John", "Doe"); var name = (First: "John", Last: "Doe"); (string First, string Last) GetName() => ("John", "Doe");
Variables declared using tuple syntax	Camel	(string first, string last) = ("John", "Doe"); var (first, last) = ("John", "Doe");
Local variable	Camel	listOfValues

[!NOTE] in case of ambiguity, the rule higher in the table wins.

Don’t include numbers in variables, parameters and type members (AV1704)

In most cases they are a lazy excuse for not defining a clear and intention-revealing name.

Don’t prefix fields (AV1705)

For example, don’t use g_ or s_ to distinguish static from non-static fields. A method in which it is difficult to distinguish local variables from member fields is generally too big. Examples of incorrect identifier names are: _currentUser, mUserName, m_loginTime.

Don’t use abbreviations (AV1706)

For example, use ChangePassword rather than ChangePwd. Avoid single-character variable names, such as i or q. Use index or query instead.

[!IMPORTANT] Exceptions: Use well-known acronyms and abbreviations that are widely accepted or well-known in your work domain. For instance, use acronym UI instead of UserInterface and abbreviation Id instead of Identity. For abbreviations of two letters, use all capitals (e.g. IO). For abbreviations longer than two letters, only capitalize the first letter (e.g. Http, Xml, Json).

Name members, parameters and variables according to their meaning and not their type (AV1707)

• Use functional names. For example, GetLength is a better name than GetInt.
• Don’t use terms like Enum, Class or Struct in a name.
• Identifiers that refer to a collection type should have plural names.
• Don’t include the type in variable names, except to avoid clashes with other variables.

Name types using nouns, noun phrases or adjective phrases (AV1708)

For example, the name IComponent uses a descriptive noun, ICustomAttributeProvider uses a noun phrase and IPersistable uses an adjective. Bad examples include SearchExamination (a page to search for examinations), Common (does not end with a noun, and does not explain its purpose) and SiteSecurity (although the name is technically okay, it does not say anything about its purpose).

Don’t include terms like Utility or Helper in classes. Classes with names like that are usually static classes and are introduced without considering object-oriented principles (see also AV1008).

Name generic type parameters with descriptive names (AV1709)

• Always prefix type parameter names with the letter T.
• Always use a descriptive name unless a single-letter name is completely self-explanatory and a longer name would not add value. Use the single letter T as the type parameter in that case.
• Consider indicating constraints placed on a type parameter in the name of the parameter. For example, a parameter constrained to ISession may be called TSession.

Don’t repeat the name of a class or enumeration in its members (AV1710)

class Employee
{
	// Wrong!
	static GetEmployee() {...}
	DeleteEmployee() {...}

	// Right.
	static Get() {...}
	Delete() {...}

	// Also correct.
	AddNewJob() {...}
	RegisterForMeeting() {...}
}

Name members similarly to members of related .NET Framework classes (AV1711)

.NET developers are already accustomed to the naming patterns the framework uses, so following this same pattern helps them find their way in your classes as well. For instance, if you define a class that behaves like a collection, provide members like Add, Remove and Count instead of AddItem, Delete or NumberOfItems.

Avoid short names or names that can be mistaken for other names (AV1712)

Although technically correct, statements like the following can be confusing:

bool b001 = lo == l0 ? I1 == 11 : lOl != 101;

Properly name properties (AV1715)

• Name properties with nouns, noun phrases, or occasionally adjective phrases.
• Name boolean properties with an affirmative phrase. E.g. CanSeek instead of CannotSeek.
• Consider prefixing boolean properties with Is, Has, Can, Allows, or Supports.
• Consider giving a property the same name as its type. When you have a property that is strongly typed to an enumeration, the name of the property can be the same as the name of the enumeration. For example, if you have an enumeration named CacheLevel, a property that returns one of its values can also be named CacheLevel.

Name methods and local functions using verbs or verb-object pairs (AV1720)

Name a method or local function using a verb like Show or a verb-object pair such as ShowDialog. A good name should give a hint on the what of a member, and if possible, the why.

Also, don’t include And in the name of a method or local function. That implies that it is doing more than one thing, which violates the Single Responsibility Principle explained in AV1115.

Name namespaces using names, layers, verbs and features (AV1725)

For instance, the following namespaces are good examples of that guideline.

AvivaSolutions.Commerce.Web
NHibernate.Extensibility
Microsoft.ServiceModel.WebApi
Microsoft.VisualStudio.Debugging
FluentAssertion.Primitives
CaliburnMicro.Extensions

[!NOTE] Never allow namespaces to contain the name of a type, but a noun in its plural form (e.g. Collections) is usually OK.

Use a verb or verb phrase to name an event (AV1735)

Name events with a verb or a verb phrase. For example: Click, Deleted, Closing, Minimizing, and Arriving. For example, the declaration of the Search event may look like this:

public event EventHandler<SearchArgs> Search;

Use an underscore for irrelevant lambda parameters (AV1739)

If you use a lambda expression (for instance, to subscribe to an event) and the actual parameters of the event are irrelevant, use the following convention to make that explicit:

button.Click += (_, __) => HandleClick();

[!NOTE] If using C# 9 or higher, use a single underscore (discard) for all unused lambda parameters and variables.

Group extension methods in a class suffixed with Extensions (AV1745)

If the name of an extension method conflicts with another member or extension method, you must prefix the call with the class name. Having them in a dedicated class with the Extensions suffix improves readability.

Only suffix methods with Async or TaskAsync when both synchronous and asynchronous variants exist (AV1755)

Only suffix a method or local function that returns Task or Task<TResult> with Async if there is also a synchronous variant of that method. If no synchronous variant exists, the Async suffix adds unnecessary noise. If both synchronous and asynchronous variants exist, use Async as the suffix. If a method suffixed with Async already exists, use TaskAsync instead.