C# Naming Standards · CS-05

All type members, parameters and variables should be named using words from the English language.

• Choose easily readable, preferably grammatically correct names. For example, HorizontalAlignment is more readable than AlignmentHorizontal.
• Favour readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).
• Avoid using names that conflict with keywords of widely used programming languages.
• Avoid using abbreviations. For example, the variable name vatPercent is better than vatPcnt.

EXCEPTION: In most projects, you will use words and phrases from your domain and names specific to your company. Visual Studio’s static code analysis will perform a spelling check on all code, so you may need to customize the Spell Checker.

Roslyn Analyzer Rule ACL1004 (partial)

NOTE: If the name of the variable includes an acronym, the acronym should follow normal casing rules for the variable type as detailed above.

For example:

• A variable for a HTTP Client should be cased as httpClient.
• A property for a HTTP Client should be cased as HttpClient.

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

Roslyn Analyzer Rule AV1704

For example, don’t use s_ or m_ to distinguish static versus non-static fields.

EXCEPTION: You should prefix private instance fields with _, e.g. _currentUser.

Roslyn Analyzer Rule SA1308.

Bad examples include SearchExamination (a page for searching 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). Good examples include BusinessBinder, SmartTextBox, or EditableSingleCustomer.

Don’t include terms like Utility or Helper in classes. Classes with a name like that are usually static classes and are introduced without considering the object-oriented principles.

Roslyn Analyzer Rule AV1708 (partial)

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

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

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

Roslyn Analyzer Rule AV1710

.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.

Roslyn Analyzer Rule AV1711 (partial)

Name Boolean members (properties, methods, etc.) consistently - so either always prefer affirmative, e.g. CanSeek, or always prefer negative, e.g. CannotSeek.

• Do name properties with nouns, noun phrases, or occasionally adjective phrases.
• 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.

Roslyn Analyzer Rule AV1715

Name methods using a verb-object pair such as ShowDialog. A good name should give the member a hint on the what, and if possible, the why. Also, don’t include And in the name of the method. It implies that the method is doing more than one thing, which violates the single responsibility principle explained in here.

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

• 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 okay.

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

public event EventHandler<SearchArgs> Search;

For events that occur before or after something (pre and post events), use the ing and ed suffixes respectively. For example, a close event that is raised before a window is closed would be called Closing and one that is raised after the window is closed would be called Closed. Don’t use Before or After prefixes or suffixes to indicate pre and post events.

Suppose you want to define events related to the deletion process of an object. Define those events as follows:

• Deleting: Occurs just before the object is getting deleted
• Delete: Occurs when the object needs to be deleted by the event handler.
• Deleted: Occurs when the object is already deleted.

It is good practice to prefix the method that handles an event with On. For example, a method that handles the Closing event could be named OnClosing.

Roslyn Analyzer Rule AV1738

If you use a lambda statement, for instance, to subscribe to an event, and the actual parameters of the event are irrelevant, use the following convention to make that more explicit.

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

Roslyn Analyzer Rule AV1739

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.

Roslyn Analyzer Rule AV1745

The general convention for methods that return Task or Task is to post-fix them with Async, but if such a method already exist, use TaskAsync instead.

Roslyn Analyzer Rules RCS1046 and ACL1005

When creating an entity, words such as “Data”, “Information”, “Fields” etc. should be avoided as they don’t add any explanatory value.