views:

367

answers:

11

I am going to be working on a bit of C# code own my own but I want to make sure that I follow the most widely accepted naming conventions incase I want to bring on other developers, release my code, or sell my code. Right now I am following the naming convention that Microsoft has set as they seem to be the most widely accepted. The one thing they don't mention though is naming for private fields. For the most part I have seen them named in camelCase like protected fields however that present me with an issue as parameter names should be in camelCase. Take the following constructor for example:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Now if I use camelCase for the private fields too there is a naming conflict unless I use "this" in order to access the class fields (which I think is against most standards not to mention means more typing). One solution is to give the parameter a different name but that does not make logical sense to give the same data 2 different names. The only other solution that I know of that was common in C++ coding is giving private members an underscore at the beginning. Is that solution commonly accepted with C# coding? Is there another solution to this problem (like only using properties (which use PascalCase) to access fields, even in the class itself)?

+14  A: 

_camelCase for fields is common from what I've seen (it's what we use).

DaveShaw
The underscore is a great identifier for me as well. I typically use m_camelCase
gooch
_camelCase for private fields is not suggested by Microsoft (http://msdn.microsoft.com/en-us/library/ta31s3bc(v=VS.71).aspx). In case of naming conflicts between class and method scope, you can use the this keyword to refer to the class member. This is also what Resharper suggests by default...
Koen
I agree with the use of the _camelCase for module level variables or property variables. But as João Angelo said already the most important thing is to be consistent. It's not about what the standards are it's that you have them and enforce them. Koen - Resharper (certainly in v5) uses _camelCase.
Daz Lewis
_We _don't _need _your _underscores _here
Callum Rogers
@Daz Lewis: ReSharper will use whatever naming convention you define in the configuration.
Martin Liversage
+1  A: 

Following Microsoft's naming conventions, private fields should be prefixed with an underscore.

For example:

private int _myValue;

Good luck!

Ian P
Identifiers should not contain underscores (it's one of the warnings from **FxCop**).
Jaroslav Jandek
It's recommended by Microsoft in their best practice guide.
Ian P
FxCop will not flag a private field starting with an underscore.
Martin Liversage
Besides, isn't that for some COM compatibility issue? I see it sometimes in the build reports, but just ignore it. I believe FxCop throws up on linq to sql auto generated classes with _ in public properties.
Ian P
FxCop doesn't care about internal identifiers but what's good for external usage should be good for internal one. Also, the underscores look ugly (IMHO).Underscore prefix did not work for some languages that were to be integrated into framework and for interop.Also having a class with 15 private fields named _whatever slows intellisense-typing down.
Jaroslav Jandek
Also I think I read like 6 years ago in naming conventions that an underscore characters should not be used as a prefix but couldn't find it now on msdn. In any case, M$ programmers use underscores all the time ;). Also, **Ian**, can you link the best practices guide?
Jaroslav Jandek
http://msdn.microsoft.com/en-us/library/xzf533w0%28VS.71%29.aspx
Ian P
@Ian P: I do not see the recommendation to use underscore prefixes anywhere. Convention only mentions underscores to not use them in classes and such.
Jaroslav Jandek
I have found the practice not to use prefixes: `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.` They do not mention non-public fields specifically, but you get the point.link: http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx
Jaroslav Jandek
To me, that reads that it is regarding hungarian notation which is not what I'm speaking about. If you read any of the microsoft employee's blogs, they all (well, all of the ones I've seen) prefix private fields with _.
Ian P
+2  A: 

Philips Healtcare C# Coding Standard

MSDN - Eric Gunnerson

Edit: I use "this" keyword to access non-static members in C# and Java.

Deniz Acay
+16  A: 

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.

tvanfosson
The naming guidelines are only concerned about identifiers visible to the outside.
Martin Liversage
@Martin - I would agree with you, but see my updated answer.
tvanfosson
+2  A: 

The most important thing is to pick one standard and stick with it. Check out iDesign's C# Coding Standard at IDesign (it's a link on the right side). It's a great document that covers things like naming guidelines. They recommend using camel case for both local variables and method arguments.

TLiebe
Our .NET dev teams the IDesign coding standards as well. Juwal can't be wrong, right? :)
Riaan
+1  A: 

The convention I use to distinguish between private class variables and method parameters is:

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}
Dougc
A: 
private string baseName; 
private string prefixName; 
private string suffixName; 

public GameItem(string _baseName, string _prefixName, string _suffixName) 
{ 
    this.baseName = _baseName; 
    this.prefixName = _prefixName; 
    this.suffixName = _suffixName; 
} 
ma7moud
-1. This convention is not posted as best practice anywhere I've seen, and the post is very poorly formatted. On a more personal level, I think the _'s in the method signature significantly clutters the code, and since it is used there and not in the private accessors, it will be visible all over the client classes too, and not just in your code.
Tomas Lycken
+10  A: 

Generally there are two widely used ways to name fields (always using camelCase):

Using an underscore prefix

void F(String someValue) {
  _someValue = someValue;
}

Using this. to access the field and avoid name conflicts

void F(String someValue) {
  this.someValue = someValue;
}

Personally I prefer the later, but I will use whatever convention is set forth by the organization I work for.

Martin Liversage
A: 

In our shop, we started our first C# project using Microsoft's suggested guideline for private members, i.e.

camelCaseFieldName

But we soon ran into confusion between private members and parameters, and switched to

_camelCaseFieldName

which has worked much better for us.

A private member usually has a state that persists outside of a method call - the leading underscore tends to remind you of that.

Also note that using AutoVariable syntax for properties can minimize the need for private backing fields, i.e.

public int PascalCaseFieldName { get; set;}

For a nice concise set of standards that (mostly) follow the MS guidelines, check out net-naming-conventions-and-programming-standards---best-practices

Tom Bushell
+1  A: 

We use StyleCop to force consistency throughout our code. StyleCop is used within Microsoft enforce a common set of best practices for layout, readability, maintainability, and documentation of C# source code.

You can run StyleCop at build time and have it generate warnings for style violations.

To answer your specific question, private fields should be in camelCase and prefixed with "this".

John Myczek
A: 

Have a look at ReSharper. It will underline all the places where your names do not confirm to ordinary guidelines, and you can customize it. Plus, of course there's loads and loads of other productivity enhancements.

Carlos