views:

373

answers:

7

Hello!

I have this class:

class DoSomething
{
    private int timesDone;
    ...
}

Which is the right way to named variable 'timesDone'?

Sometimes I see named as m_timesDone. Is this correct? Where I can find information about naming guidelines?

Thank you!

+2  A: 

You can find some information directly on the MSDN site: http://msdn.microsoft.com/en-us/library/ms229002.aspx

cedrou
This is the new version: http://msdn.microsoft.com/en-us/library/ms229002.aspx
Joren
Of course, they do not seem to specify a casing convention for private instance variables :)
Ed Swangren
True, they don't.
Joren
+5  A: 

There is no universal right way. Chose a naming convention of your liking and stick with it.

Jonas Elfström
Or, better yet, use one to the liking of your entire team. Standards should be a collaborative effort and not a one person dictation - unless you are the only person on the team, that is.
joseph.ferris
I totally agree. Also you should look around for examples of good conventions just so you don't have to make some silly mistakes.
Jonas Elfström
+3  A: 

Many people do as you have it there. You would then reference it as

this.timesDone = someInt

However, I don't like this because I am not a fan of typing 'this' to avoid clashes with method parameter names. As long as it is readable and consistent you will be fine.

Ed Swangren
+1 - THANK you! I got hammered on another thread for daring to say that you don't need "this" most of the time.
TrueWill
+4  A: 

According to MS standards your code is OK. Having prefixes as m_ is not really necessary when you have advanced IDE. However short prefix like _ can be used to take advantage of auto complete feature to quickly sort out class members.

I would recommend you to get a copy of "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book to learn more on MS standards

aku
the m_ or _ or whatever is necessary if you don't feel like prefacing each variable with 'this'
Ed Swangren
@EdSwangren, it is very unusual situation when you have to use "this." construction. if you are using descriptive names you will find that the only place you need it (but not required to) is constructor
aku
Yep - MS does not have guidelines for private fields. We use underscore. Definitely get Framework Design Guidelines - note that there is a second edition: http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613
TrueWill
I'm reading this book now and it said that all identifiers uses Pascal notation except parameters that use camel notation. I haven't see anything about private fields.
VansFannel
@aku: I don't agree. Say I have a private instance field name, and a constructor which takes a parameter "name", or a method, etc. I would run into it all of the time if I used that convention.
Ed Swangren
Though I suppose that, in that case, "name" would probably be a public property, i.e., "Name", so it would not clash. Bad example :)
Ed Swangren
StyleCop warns against Hungarian notation and using variables with an underscore at the beginning
Alex Baranosky
@aku, additionally, StyleCop recommends using this as a qualifier everywhere applicable. It does help in the regard if instantly determining that something is scoped to the class, as opposed to an individual method. More stylistic opinion than anything concrete, though.
joseph.ferris
+4  A: 

Definitely do not use m_timesDone.

Simply put "private int timesDone".

You can learn about how to name variables by reading some good books such as Code Complete.

Alex Baranosky
Uh...why not? Sounds a bit dogmatic to me, -1
Ed Swangren
It's against the coding guidelines. It isn't the way C# is written. Just like you don't start methods out with lowercase letters.
Alex Baranosky
It's personal/company preference, really. Private fields are an irrelevance when it comes to the public API so using (or not using them) isn't going to go against .NET standards IMO.
Mark Simpson
AFAIK the guidlines don't say anything about *private* stuff. I personally prefer `_privateField`, because then I can have ctor parameters named `privateField` and you can immediately see the difference between a local variable and an instance field.
SealedSun
+3  A: 

The convention of prefacing member fields with m_ comes from the early days of C++, when Hungarian notation was popular. It is not a C# convention, and since most C# code is written using a recent Visual Studio it adds visual noise without any corresponding advantage, because you can easily see the scope of a variable anyway. Do not use m_.

The lone example of Hungarian notation that has found its way into C# is the practice of prefacing interface class names with I, such as IDisposable.

RossFabricant
Many people also habitually start type parameters with T, which is somewhat Hungarianesque.
Eric Lippert
@Eric, is that something to be avoided in your opinion? Isn't this what MS does too in the BCL?
Joan Venge
A: 

The Strategy usually adopted is :

For Class & Method: Pascal Casing

e.g.

public class Program
 {
 }

e.g

public void DoSomething() { }

For Variables: Camel Casing e.g. timesDown

Local Variables:

   aTimesDown

Global Variable:

myTimesDown

I hope this may help you :)

Amit
**NB** These apply to public/protected members and public non-member classes. There is no guidance on private members.
Richard