views:

728

answers:

8

Hi

There is too much discussion about the class fields naming, but the major difference is this:

private int foo;

private int _foo;

Can anyone tell us, what's the latest decision about this convention?

Thank you!

+1  A: 

The latest decision according to "official" Field Usage Guidelines is:

private int foo;

Field names are written by convention in camelCase.

Also read Naming Guidelines - .NET Framework General Reference

Developer Art
The trouble with t'Internet is you can never tell if someone's joking.
serialhobbyist
I like it. Esp. the "latest decision" part (who decided it btw)?
shahkalpesh
where did that come from ? PascalCasing is for public members, not private fields...
Thomas Levesque
Can you provide the source of this information?
Fredrik Mörk
"Do not use uppercase letters for field names" - http://msdn.microsoft.com/en-us/library/ta31s3bc(VS.71).aspx
Stuart Dunkeld
You should clarify that this refers only to *const* and *static readonly* fields, and your example mentions a *private instance* field.
280Z28
I think you misread the guidelines... It says to use Pascal for "public instance fields", and doesn't say anything about private fields
Thomas Levesque
Interesting, I never knew that. Thanks guys for pointing it out to me.
Developer Art
+2  A: 

The "usual" naming convention is to have the underscore for the private field and the same name without the underscore for the corresponding (if any) property.

Otávio Décio
This is what we do. Seems simple enough and if you look at a lot of the official .NET framework code that's what MS seems to do (well, most of the time).
Yadyn
+2  A: 

I certainly won't start comparing myself to Jon Skeet, but here's my take on it.

You have two situations:

  1. You always prefix your field accesses with this..
  2. You do not.

For each of these cases:

  1. Preference, judgement call.
  2. Use a prefix for private fields. I don't care what it is, but pick something and stick with it. It seems the two common ones are m_ and just _.

In either case, be consistant, like with anything.

Matthew Scharley
A: 

Who's going to NameCon next year?

Nick
+17  A: 

Here's what I've found:

"Recent" code in the .NET Framework has used both (though never in the same class, and generally the difference is across teams as a whole - WPF might use something different from Parallel FX (haven't checked if they do), but WPF blending effects would use the same as WPF text rendering).

StyleCop "suggests" using foo as a member field instead of _foo, and referencing it as this.foo inside of class members. The rationale there is:

  1. Using this.memberName is clearer than memberName and
  2. When using this.memberName, the _ doesn't do anything in regards to identifying the reference as a member field, because the this. already did that. Unndecessary redundancy clutters code, therefore no _ prefix.

I personally, IMO prefer _foo for two reasons that form the rationale for the other method you've observed:

  1. Reducing the number of aliased names in methods
  2. I can still keep parameter names with the same (exact) spelling and casing as member fields. With the only change being the underscore, it just seems clearer to me.
280Z28
I just checked StyleCop and found the same, and I also prefer the underscore thing for the same reasons, so this is +1. Luckily you can just disable rule SA1309 (Field names must not start with an underscore).
OregonGhost
The funny part is that ReSharper may later suggest to remove `this.` since it is redundant. I also like the underscore because it will make intellisense list all private fields near each other.
Fredrik Mörk
Oh the irony... One tool to make us better suggest one thing, only to have a second tool tell us we were right the first time...
Matthew Scharley
Dear whoever marked me down without a reason: my answer is an objective presentation of evidence shown to me followed by a *very* clearly labeled subjective comment for the sole purpose of providing the rationale for the other side of the argument. It's the best way to explain to the OP where this debate came from and why people have broadly fallen into the two mentioned opinions out of all the options available.
280Z28
Jeff Sternal
@ OregonGhost: if you're going to disable a rule, because it goes against your team convention, then it's advisable to write a custom StyleCop rule to replace the one you've disabled. It's quite easy to do as well, and avoids naming convention issues that arise from disabling the rule.
Andrew Johns
A: 

Personally I prefer _foo for a private field and Foo for a public field as follows

private string _foo;

public string Foo 
{
    get { return _foo; }
    set { _foo = value; }
}
GaryDevenay
+5  A: 

We follow this, which is a summary of MS .NET practices: http://www.irritatedvowel.com/Programming/Standards.aspx

Then it would be underscore for private fields.

private int _foo;
Arjan Einbu
Was this downvoted for being incorrect, or you just don't agree with me?
Arjan Einbu
A: 

Use StyleCop

John Gietzen
While I agree with most of the rules, team members have the right to disagree. Otherwise, these would be syntax rules, rather than suggestions. On the other hand, ignoring all StyleCop rules essentially defeats the purpose. Use what works for your team and just be consistent. Personally, I prefer the underscore over using "this." all over the place.
senfo