Reputation: 7092

Is there any C# naming convention for a variable used in a property?

Let's say, we have a variable, which we want named Fubar

Let's say that Fubar is a String!

That means, we would define Fubar as so:

public string Fubar;

Now, let's say we want Fubar to have a getter and setter (or in other words, become a C# property)!

private string Fubar;
public string Fubar_gs
{
    get
    {
        //Some fancy logic
        return Fubar;
    }
    set
    {
        //Some more fancy logic
        Fubar = value;
    }
}

Well great! That is all fine and dandy, EXCEPT, what if I wanted the PROPERTY to be named Fubar, not the original variable?

Well obviously, I would just rename both variables. But the problem is, what would be the best name for the original variable?

Is there a naming convention for this situation?

Upvotes: 52

Answers (12)

Keith Nicholas

Reputation: 44288

prefix the private with an underscore _fubar

as a good guide, you can use the CLR runtimes teams coding style guide which goes beyond the standard naming guideline from Microsoft

https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md

Upvotes: 10

dylanh724

Reputation: 1018

I see a ton of outdated answers (and non-standard ways representing C#6), so this one's for 2020:

// "fubar" works, too, but "_" prevents CaSe typo mistakes
private string _fubar;
public string Fubar
{
    get => _fubar;
    set => _fubar = value;
}

// Read-only can just use lambda to skip all those shenannigans
public string ReadOnlyFoo => "This is read-only!";

Upvotes: 1

Abedron

Reputation: 771

I thing, one name is better:

public string Fubar { get; private set; }

Upvotes: 2

Daniel Mann

Reputation: 58980

Per Microsoft's naming conventions, the proper way would be:

private string fubar;
public string Fubar { get { return fubar; } set { fubar = value; } }

However, many people prefer to prefix the private field with an underscore to help minimize the possibility of miscapitalizing and using the field when they meant to use the property, or vice versa.

Thus, it's common to see:

private string _fubar;
public string Fubar { get { return _fubar; } set { _fubar = value; } }

The approach you take is ultimately up to you. StyleCop will enforce the former by default, whereas ReSharper will enforce the latter.

In C# 6, there is new syntax for declaring default values for properties or making read-only properties, lessening the need for properties with backing fields that don't have any special additional logic in the get and set methods. You can simply write:

public string Fubar { get; set; } = "Default Value";

public string Fubar { get; } = "Read-only Value";

Upvotes: 146

uceumern

Reputation: 937

Well, the Framework Design Guidelines document states the following:

Names of Fields The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines, and public or protected instance fields are not allowed by the member design guidelines.

✓ DO use PascalCasing in field names.

✓ DO name fields using a noun, noun phrase, or adjective.

X DO NOT use a prefix for field names.

For example, do not use "g_" or "s_" to indicate static fields.

So, for private fields, there is no official recommendation. However, if you use VS 2017 quick action "Convert to full property" on a property, this happens:

So it seems like it is safe to assume that prefixing private fields with an underscore is somewhat standard.

Upvotes: 5

Richard Fu

Reputation: 626

While most developers follow Microsoft's guideline, as game developers, we follow Unity's style as (one of the script source code here):

static protected Material s_DefaultText = null;
protected bool m_DisableFontTextureRebuiltCallback = false;
public TextGenerator cachedTextGenerator { ... }

Upvotes: 0

CoffeDeveloper

Reputation: 8317

Unluckily there are no common convention, you have to choose what suits most your case, I've seen all the following approaches in different codebases.

Approach 1

private string _fubar;   //_camelCase
public string Fubar { ... }

Approach 2

private string fubar;    //camelCase
public string Fubar{ ... }

Approach 3

private string _Fubar;    //_PascalCase
public string Fubar{ ... }

Also there are frameworks that takes much creativity like using a property and document it as a member variable and thus using member's styling instead of the properties' styling ( yeah Unity! I'm pointing the finger at you and your MonoBehaviour.transform 's property/member)

To disambiguate in our code base we use our homemade rule:

Try to use more proper naming, usually a member used inside a public property has a slightly different purpose than its public counterpart, so it is very possible most times to find a different and proper name, and if not possible its purpose is just holding state for the public property, so why not naming it nameValue?
use autoproperties if possible

With our approach most times we avoid the doubt about the underscore "_" while at same time having a much more readable code.

private string fubarValue; //different name. Make sense 99% of times
public string Fubar { ... }

Upvotes: 4

CaffGeek

Reputation: 22054

The c# way is

private string _fubar;
public string Fubar
{
    get
    {
        return _fubar;
    }
    set
    {
        _fubar = value;
    }
}

However, if it's just a basic getter/setter with no extra logic, you can just write

public string Fubar { get; set; }

No need for a backing variable or anything.

Upvotes: 2

Olioul Islam Rahi

Reputation: 39

Another way to declare with a default value

    private string _fubar = "Default Value";
    public string Fubar
    {
        get { return _fubar; }
        set { _fubar = value; }
    }

Upvotes: 1

Nicholas Carey

Reputation: 74187

The nice thing about coding standards is that there are so many to choose from:

Pick a convention that suits you and use it consistently.

The Microsoft convention — pascalCase private fields and CamelCase properties is tidy, but can lead to bugs due to typos. I find the leading underscore convention annoying as it requires two additional key strokes every time you type the name, but you don't get the typos so much (or at least the compiler catches them first).

Upvotes: 2