On C# naming conventions for member variables

Question

I have seen an advice somewhere here on SO to not name private/public member variables, in a way that they differ only by the case of the very first character. For instance:

private string logFileName;

public string LogFileName
{
    get
    {
        return logFilename
    ....

and: private System.Windows.Forms.MainMenu mainMenu;

and: DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();

and:

public Version Version
{
    get;
    set;
}

and:

    private void CheckPollingType(PollingType pollingType)
    {

So, did I hear wrong? Is there anything wrong with these naming conventions? If yes, then what are better ways of doing it? Links, references are a plus.

Thanks.

Answer 1

That is definitely a very popular naming convention and I don't see why you should be against it.

I would simply recommend following the Naming conventions for C# provided by MSDN and also General Naming Conventions provided by MSDN.

Specifically they have this to say about properties:

Do name properties using a noun, noun phrase, or an adjective.

Noun phrases or adjectives are appropriate for properties because properties hold data.

Do not use properties that match the names of Get methods.

For example do not name a property EmployeeRecord and also name a method GetEmployeeRecord. Developers will not know which member to use to accomplish their programming task.

Do name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value.

Consider giving a property the same name as its type.

When you have a property that is strongly typed to an enumeration, the name of the property can be the same as the name of the enumeration. For example, if you have an enumeration named CacheLevel, a property that returns one of its values can also be named CacheLevel.

I think if there were a compelling reason to be against what you are suggesting they would have mentioned it in their guidelines.

Answer 2

No there is nothing wrong with these naming conventions.

The property version is actually the recomended format according to the .Net framework design guidelines.

The field declaration likewise conforms to the framework guidelines as it's camelCased. It's occasionally a bit of a religous war as to whether or not the variable should be prefixed with a _ or m_. That's a question that needs to be resolved within your group though.

.Net framework design guidelines for type members

• http://msdn.microsoft.com/en-us/library/ms229012.aspx

Answer 3

Most of the time class level variables are prepended with an underscore. So myVariable is actually _myVariable. A lot of people don't like varrying the name by one character, because it is too easy to make a mistake.

There is nothing wrong with just doing myVariable and MyVariable. It's just a convention, and if everyone follows it then it will probably work just fine.

Personally if at all possible I dispense with the private variable and just use the getters and setters in the property. Most of the time (but not all the time), accessing the private variable was used to to not allow write access in the property.
This can be solved by:

public String MyVariable
{
   get;
   private set;
}

Answer 4

Typically, I always see private members with a leading _. (assuming it's not an auto property)

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

Of course, the final verdict is the convention of your team (assuming you aren't doing a lone wolf project or working with utter morons)

Answer 5

What ever naming convention you do choose - be consistent. Then at least when you come back to the code in six months time, or when someone new looks at it for the first time, they'll be able to work out what's what.

Answer 6

Hi,

Here is the definitive guidline from Microsoft.

I would also recommend this book if you are at all interested in the details and reasons behind the naming and style conventions used across the .NET framework.

Enjoy!

Answer 7

Be careful of this scenario though:

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

Visual Studio will warn you about this situation, but it's not illegal and can slip through sometimes.

Answer 8

I will throw my hat in the ring with what I have always used

class ClassName //Classes are capitilzed
{
    public ClassName(int myPropriety)
    {
       _myPropriety = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are captilized, passed pramaters are lowercase.
    {
        int sampleVar; //local variables are lowercase
    }
    public int MyPropriety { get { return _myPropriety; } } // Proprieties are caplized

    private int _myPropriety; // Fields are lowercase and start with a _

Answer 9

the main issue with same name with different case, is that not all languages in .net are case sensitive i.e. visual basic.

The only scenario where that's a real issue is when you are exposing public members that only vary by case. There is a compatibility attribute one can set so the compiler tells you if you have one of such scenarios.

Above said, this doesn't really affect the scenario of the backing private member.

Answer 10

The basic problem with the naming convention proposed is Intellisense will use the private variable over the property. In many cases that's not actually a problem (is, in fact, usually a good thing), but for those few cases where it is, a convention that separates the two names is useful. I like m_ for private member variables and c_ for private static variables.

Answer 11

One reason I can think to not use case to differentiate public vs private members is that Visual Studio Intellisense will sort both members right next to each other, so you might use the wrong one without noticing.

That being said, I use the convention you described (using case to differentiate accessibility) in my code, and I haven't had any problems.

Answer 12

If you're only doing C# it's no problem, but if you (or your team/company) are also doing VB.Net (which is case insensitive), then I'd recommend that it might be better to not do this in C# either so that the naming conventions between different languages don't differ too much.

Answer 13

The two most popular conventions I see are prefixing private member variables with either a _ or m_. I personally prefer the m_ convention, but as long as it's consistent across the project/team, I really don't care. I'm not one to get into 'religious wars' :)