3

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!

abatishchev
  • 98,240
  • 88
  • 296
  • 433
VansFannel
  • 45,055
  • 107
  • 359
  • 626
  • 2
    m_, s_, etc. are discouraged for public members by the guidelines cedrou pointed you to. I don't think the official guidelines say anything about private fields. I usually just use `timesDone` for private fields and `TimesDone` for the exposing property. When I'm setting the field in a constructor, I call the parameter `timesDone` and refer to the field as `this.timesDone`. I find `_timesDone` for the field, `timesDone` for the parameter and `TimesDone` for the property an acceptable combination as well. But this is all just my opinion. You should form your own. :) – Joren Sep 27 '09 at 07:24

8 Answers8

5

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

Jonas Elfström
  • 30,834
  • 6
  • 70
  • 106
  • 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 Oct 08 '09 at 17:59
  • 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 Oct 08 '09 at 22:35
4

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
  • 122,288
  • 32
  • 173
  • 203
  • the m_ or _ or whatever is necessary if you don't feel like prefacing each variable with 'this' – Ed S. Sep 27 '09 at 07:23
  • @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 Sep 27 '09 at 07:26
  • 1
    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 Sep 27 '09 at 14:57
  • 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 Sep 27 '09 at 17:16
  • @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 S. Sep 27 '09 at 19:24
  • 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 S. Sep 27 '09 at 20:31
  • StyleCop warns against Hungarian notation and using variables with an underscore at the beginning – Alex Baranosky Oct 04 '09 at 21:21
  • 1
    @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 Oct 08 '09 at 17:58
4

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
  • 48,865
  • 44
  • 102
  • 150
  • 2
    Uh...why not? Sounds a bit dogmatic to me, -1 – Ed S. Sep 27 '09 at 19:22
  • 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 Sep 28 '09 at 03:13
  • 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 May 08 '10 at 23:20
  • 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. – Christian Klauser May 08 '10 at 23:22
3

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 S.
  • 122,712
  • 22
  • 185
  • 265
  • +1 - THANK you! I got hammered on another thread for daring to say that you don't need "this" most of the time. – TrueWill Sep 27 '09 at 14:58
3

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
  • 12,364
  • 3
  • 41
  • 50
2

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

cedrou
  • 2,780
  • 1
  • 18
  • 23
  • 1
    Of course, they do not seem to specify a casing convention for private instance variables :) – Ed S. Sep 27 '09 at 07:22
1

The only point of agreement that you will find is that it should not be TimesDown, but that it should start with a lower case letter.
In older publications (MS, MSDN), the use of a leading underscore is discouraged. Later it is back, especially for backingfields for properties: _timesDown.

H H
  • 263,252
  • 30
  • 330
  • 514
0

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
  • 1,007
  • 5
  • 13
  • 19
  • 1
    **NB** These apply to public/protected members and public non-member classes. There is no guidance on private members. – Richard Sep 27 '09 at 08:58