To _, or not to _?

The .NET Framework is littered with private variables preceeded with the _ (underscore) character. Is this good practice Or something Microsoft are trying to stamp out

Visual C#6

its not about best practice but rather naming conventioning/schemes.

there was a doc about this...

http://msdn2.microsoft.com/en-us/library/ms229045.aspx

I can't remember if it covers this stuff but take a look, hope you find it useful in some way

To be fair the DCL document is for exposed (public/protected) members. It somewhat states this in the intro to the document but makes it more clear as you read along. Therefore what you name your private members (whether they be fields, methods or even types) is completely up to you. However for consistency it is recommended that you follow the same guidelines irrelevant of the accessibility of elements. This saves time later if the accessibility changes.

As far as the whole underscore, hungarian notation argument you should decide for yourself the standard that you will use. Use the syntax you feel most comfortable with. IMHO there are more important discussions to have about code than whether or not to use underscores or hungarian notation. Honestly if your development team has nothing more important to argue about than notation then I want to join your team because you have it easy. Unfortunately this area is a religious war between developers so don't join in the fray. So, in a nutshell follow the DCL guidelines for public/protected items and whatever style works best for you for privat items but strive for consistency. If you don't have a personal style then stick with the DCL guidelines as they work just as well for private items. JMO.

Michael Taylor - 11/28/06

Michael, your reply was a rather laborious, waffle-ish and what some my consider "offencive"...

However, [despite your unfortunate manner], you make a good point that the naming of private variable/fields/methods is down to personal preference.

Well said!

I like it on private fields that HAVE a public property getter / setter. The extra reach of a shift + _ character makes it more likely developers will do the right thing and use the Property instead!

It also makes code-reviews looking for code written directly against the private fields rather than property values easier to spot.

So - I use _ ONLY for private fields that have a property getter/setter defined. Its my marker for "use the property instead" (this is important in case any extra code is in the property Get or Set which would be bypassed if going direct to the field)

Hope that helps,
Troy.

Cool. I like it.

I use the underscore to help make things a little less confusing in the ctor.

_someField = someField;

... rather than how I used to do it ...

this.someField = someField;

I do personally use the "_" prefix for private fields, so I don't need to clarify private field usage with the "this." prefix. However, not everybody here at work does that. :)

I do NOT name private methods with a "_" prefix; instead, my private methods start with a lowercase letter instead of an uppercase one, so you can instantly tell if a method is private or public/internal.

(If you need to make a private method public, you need to rename it, but this is trivially easy using the built-in refactoring feature of Visual Studio.)

Hello,

This is truly a debatable topic and many discussions has been already done on it. I would like to contibute a little on it. I worked on .Net Coding standard for my organization about a year back. And from my Study I learnt that Microsoft is moving intentions of their programmers community from old m_ or _ style to new standards which are recomended to be used in .Net. use of "_" and hungarian notation is forbidden.

As many other people have said that it depends on the way you feel comfortable I go with this statement but I can't see any problem in getting familiar with new style quickly and easily. I thing we can adopt it with 2-3 days programming. Personally I and my company strictly use the new Standards defined for .Net. A good explaianaiton can be found here on MSDN...

http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp

Here many people will repel me that Microsoft's own emplyees use _ in their programming style and its proved after seeing hundreds of examples in MSDN using _ in code. Why Microsoft doesnot force her own employees first to follow these rules first and then ask others to do it Here is again the same thing "Most of people writing these documents are experienced and are working in this field for decades, they are still sticked with C++ style and feel comfort in it "

In my point of view, as time passes, things are changed, time changes, new lanuages are created, new standards are defined, we should be with time and stay current always. Why would one like to learn C# 3.0 The reason is straight forward that he wants to stay current. So I think we loose nothing if we adopt the new thing.

Two more Recomendations to you are:

1) Please read this document and do not forget to read the Threads at the end of articles, there is a real war between developers from around the world on the same thing.

2) Use FxCop (Code Analysis Tool) It'll keep you aligned with Microsoft Guidelines. FxCop is free tool from Microsoft and can be downloaded after searching google.

Best Regards,

Rizwan

Very interesting Rizwan. After reading about Microsoft's intentions, I can't help but feel that I'm taking a step back by prefixing _'s.

Note that the sample microsoft code uses "this." as a prefix instead of "_".

See for example: http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp

The underscore is used, as I see it, so that the class libraries containing variable/property pairs would be CLS-compatible. If variable is called myVariable and property is MyVariable, it is not CLS-compatible, because some languages are case-insensitive. So I'd advice to use underscore with member variables at least with class libraries.

CLS compliance is only affected by externally visible members. If your variable is private then it has no effect on whether the code is CLS compliant, irrespective of its name.

For your information:

Following the rumour about Microsoft encouraging their internal teams to deprecate the use of an underscore prefix for private fields, I have decided to do the same.

I have always thought the leading underscore was an abomination. The general move to remove the need for any leading notation to indicate variable type was a good one, but for some reason the leading underscore lived on. I feel vindicated now!

If you can't easily work out where the variable is defined (local scope, local parameter, member variable) then your code is too complex and needs refactoring. It's that simple.

this.myVariable = myVariable is far more explicit, and should be encouraged over _myVariable = myVariable.

And don't even get me started on people who prefix variable names with 'the'.

again its personal preference. At the end of the day variable names doesnt matter, its only for us humans.

private string theTitle = "Handle it!";