What Are the Naming Conventions in C#

Naming Convention in c#

Microsoft has an excellent set of guidelines on class library design, including a section on naming. In short (examples in parentheses):

• Classes/Structs: PascalCase (WebRequest)
• Interfaces: PascalCase with I prefix (IDisposable)
• Methods: PascalCase (ToUpper)
• Properties: PascalCase (Length)
• Events: PascalCase (Click)
• Namespaces: PascalCase (System.Collections; unusual to have two words in one part though)
• Non-constant variables including parameters: camelCased (keySelector)
• Constants: PascalCase (Int32.MaxValue)
• Enums: PascalCase, singular for non-flags and plural for flags (HttpStatusCode, BindingFlags)
• Attributes: PascalCase with "Attribute" suffix (ThreadStaticAttribute)

Private names are up to you, but I tend to follow the same conventions as for everything else. Hungarian notation (in the style of Win32) is discouraged, although many places use "m_" or "_" as a prefix for instance variables.

C# naming conventions for acronyms

There is a convention, and it specifies initial uppercase, the rest lowercase, for all acronyms that are more than 2 characters long. Hence HttpContext and ClientID.

What are the naming conventions in C#?

There is the All-In-One Code Framework Coding Standards from Microsoft which contains a complete set of rules and guidelines. (also used to be available here)

This document describes the coding style guideline for native C++ and .NET (C# and VB.NET) programming used by the Microsoft All-In-One Code Framework project team.

C# Field Naming Guidelines?

Follow the Microsoft Naming Guidelines. The guidelines for field usage indicate that it should be camelCase and not be prefixed. Note that the general rule is no prefix; the specific rule is not to prefix to distinguish between static and non-static fields.

Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

and (from General Naming Conventions)

Do not use underscores, hyphens, or any other nonalphanumeric characters.

EDIT: I will note that the docs are not specific with regard to private fields but indicate that protected fields should be camelCase only. I suppose you could infer from this that any convention for private fields is acceptable. Certainly public static fields differ from protected (they are capitalized). My personal opinion is that protected/private are not sufficiently different in scope to warrant a difference in naming convention, especially as all you seem to want to do is differentiate them from parameters. That is, if you follow the guidelines for protected fields, you'd have to treat them differently in this respect than private fields in order to distinguish them from parameters. I use this when referring to class members within the class to make the distinction clear.

EDIT 2

I've adopted the convention used at my current job, which is to prefix private instance variables with an underscore and generally only expose protected instance variables as properties using PascalCase (typically autoproperties). It wasn't my personal preference but it's one that I've become comfortable with and probably will follow until something better comes along.

c# Naming Convention

The C# naming convention recommends everything that is public as well as classes, interfaces etc., to start with an uppercase letter. The rest should start lower case.

There is no problem with:

private User User { get; set; }

... since the position of each name (word) defines what is what.
The English language works the same way.
e.g.: "I love love." (pronoun, verb, noun)

Naming Conventions in C# - underscores

A good article to read on the development of C# style guidelines is here at C# coding conventions.

The original guidance for .NET was to never use underscores unless they were part of a private member variable, and then only as a prefix, e.g. _customerId. This was probably inherited from MFC where 'm_' was used as a prefix for member variables.

Current practice is not to use underscores at all. Disambiguation between private member variables and parameters with the same name should done using 'this.'. In fact all references to private members should be prefixed with 'this.'.

The only place underscore seems to be used a lot is in unit test methods. I'm not a fan, but it may make the methods more readable, for example Throw_If_Customer_Is_Null(){...}.

Naming Convention for var in C#

I think you misunderstand what var means and confuse between what is the class, the reference and the var (and therefore naming conventions of each).

So what var is? From docs:

variables that are declared at method scope can have an implicit "type" var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type

From Implicitly Typed Local Variables:

The var keyword instructs the compiler to infer the type of the variable from the expression on the right side of the initialization statement

So in this case var converter = new Converter();:

• The compiler determines the var as Converter.
• You are creating a reference named converter - which should be named using camelCaseing.
• The explicit type of the reference is Converter - which should be named using PascalCasing.

Writing var converter = new Converter(); is identical to writing Converter converter = new Converter();

---

In C# var is for for cases where you do not know the explicit type such as anonymous types or as a easy way to write:

Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>> variable = 
    new Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>>();

as this:

var variable = new Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>>();

As it is an "alias" for the type but not the type itself it keeps to the conventions of the language keywords (and not types) and is written in lower case.

Events - naming convention and style

There are a few points that I would mention:

Metronome.OnTick doesn't seem to be named correctly. Semantically, "OnTick" tells me it will be called when it "Tick"s, but that isn't really what's happening. I would call it "Go" instead.

The typically accepted model, however would be to do the following. OnTick is a virtual method that raises the event. This way, you can override the default behavior in inherited classes easily, and call the base to raise the event.

class Metronome
{
    public event EventHandler Tick;

    protected virtual void OnTick(EventArgs e)
    {
        //Raise the Tick event (see below for an explanation of this)
        var tickEvent = Tick;
        if(tickEvent != null)
            tickEvent(this, e);
    }

    public void Go()
    {
        while(true)
        {
            Thread.Sleep(2000);
            OnTick(EventArgs.Empty); //Raises the Tick event
        }
    }
}

---

Also, I know this is a simple example, but if there are no listeners attached, your code will throw on Tick(this, EventArgs.Empty). You should at least include a null guard to check for listeners:

if(Tick != null)
    Tick(this, EventArgs.Empty);

However, this is still vulnerable in a multithreaded environment if the listener is unregistered between the guard and the invocation. The best would be to capture the current listeners first and call them:

var tickEvent = Tick;
if(tickEvent != null)
    tickEvent(this, EventArgs.Empty);

I know this is an old answer, but since it's still gathering upvotes, here's the C# 6 way of doing things. The whole "guard" concept can be replaced with a conditional method call and the compiler does indeed do the Right Thing(TM) in regards to capturing the listeners:

Tick?.Invoke(this, EventArgs.Empty);

---

Related Topics