"this" for member variable? why not "m_" or just "_" like old times?

Question

Recently I've taken note of class member variables in C# moving to the this.foobarbaz for every reference for class member variables rather than the previously acceptable m_ or just _. How many of you seasoned programmers are coding to this new acceptable standard, if so why, if not why? I ask because it changes our coding standards at work, it may be a tough sell for some. So then I ask: what would be a static class var? s_ or that.foobarbaz Okay okay just kidding. Thanks - Old man.

Answer 1

The keyword this is simply used to specify that we are referencing this very instance. One is not obliged to always specify this, except if one wants to make it obvious that the variable is one of the instance, and not a parameter or something alike.

Most of the time, I see the underscore character to designate field members, and rarely m_.

Answer 2

It fits better with the code from the framework, General Guidelines in the Capitalization Conventions section. I'm quite sure the m_ and _ is from before .NET 1.0, back in Visual Studio 6.

Choosing identifiers that conform to these guidelines improves the usability of your library and encourages users to trust that your library will not require learning a new set of conventions.

Since local variables are also camel cased, the 'this' differentiate the variables that are members of the class, most syntax tools (StyleCop, FXCop, CodeIt.Right) will flag class members missing this , or containing _ and m_ as warnings.

Answer 3

That sort of syntax is necessary when the class member variables have the same name as the local variables passed in to a function or constructor.

public class Foo 
{
    private string name;

    public Foo(string name) 
    {
        this.name = name;
    }
}

personally i find it a PITA when devs code that way, and prefer to have an underscore prefixed to the member variable just like old times.

Answer 4

Because this is only used when necessary. Adding a prefix to an identifier forces you to use it everywhere, which is very inconvenient.

_ or m_ prefixes are a C++ leftover that's not appropriate for C#.

Answer 5

First, read "Framework Design Guidelines" (Cwalina/Abrams). Then, download and use FxCop. It will teach you so much and (hopefully) change your outlook on coding, for the good.

Next, aside from best-practices being "the time-tested, best way to approach a problem", sometimes, if there are several "right" answers, you pick one for consistency sake. With naming standards, it's "slightly" more intuitive to get away from hungarian notation, SCREAMING_CAPS, and abbreviations for example - to instead use PascalCase and camelCase. This convention is now the accepted standard. It's not wrong to use the other styles, but there certainly is no advantage to it.

Lastly, from your post, the "this" keyboard is not a prefix. It is a language convention (in VB.NET, it's "Me"). When you use this.variableName, you are simply being very specific is saying "I am referencing a class-level member, of the current instance. It's not an arbitrary prefix. Hope that helps.

Answer 6

My own preference is to only adorn interfaces with the 'I' prefix. Everything else (including member, static and control related variables) get pascal casing with no prefixs (especially hungarian or underscores).

Answer 7

Often, when I see lots of this.Member in .NET code, it's not so much a style choice as an indicator that the original coder was trying to bring up IntelliSense; typing this. is one way to do this, but unfortunately it leaves a trail behind.

Learning the keyboard shortcut (Ctrl-J) gives you a bigger list to sift through, but leaves cleaner code.

Answer 8

I am a fan of using "this." The single biggest reason is that this tells the compiler what you intended, and it can give you warnings / errors when something is wrong. You can't get this from m_.

Almost everyone I talk to about "this." is resistent. More typing, don't see the value, etc, change is scarey, etc, etc. Trying to convince someone (never mind a team) to do this is painful for everyone. Either they see the value, or they don't.

For statics, internal to the class I don't do anything, external to the class I use the class name.