问题
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?
回答1:
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";
or
public string Fubar { get; } = "Read-only Value";
回答2:
prefix the private with an underscore _Fubar
回答3:
If you name your private variables starting with lower case, you can right click on them and have VS generate your getter/setter code for you;
Refactor->Enacpsulate Field...
It will name the property with Caps.
回答4:
If there's no logic in the getter/setter, use an auto-property:
public string Fubar {get; set;}
http://msdn.microsoft.com/en-us/library/bb384054.aspx
回答5:
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 { ... }
回答6:
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.
回答7:
The nice thing about coding standards is that there are so many to choose from:
- http://www.google.com/search?q=c%23+coding+standards
- http://blogs.msdn.com/b/ericgu/archive/2004/01/19/60315.aspx
- http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html
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).
回答8:
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.
回答9:
I thing, one name is better:
public string Fubar { get; private set; }
回答10:
Another way to declare with a default value
private string _fubar = "Default Value";
public string Fubar
{
get { return _fubar; }
set { _fubar = value; }
}
回答11:
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 { ... }
回答12:
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!";
来源:https://stackoverflow.com/questions/12045711/is-there-any-c-sharp-naming-convention-for-a-variable-used-in-a-property