m_

[Ne0mega]

necessary and helpful or archaic and ugly?

[MelvMay]

There are no absolutes in this kind of thing. Subjective and irrelevant is my choice.

[Gladyon]

‘m_’ has an use.
It is up to you to know if it is important to your or not, and if it is, it is up to you to choose how to achieve it.

‘m_’ is used to force the devs to make a difference between local variables and member variables.
The reason it is important is that when you are using a member variable you may be ‘disturbed’ by something exterior to your current method.
And if you modify a member variable you may wreak havoc in another method.

If you are using/modifying a local variable, then any problem you can have/cause will be local to the current method.

That’s why it is important to always have in mind the ‘range’ of what you are using, is it local or is it ‘global’?
It’s about the same thing as private/public members, members are declared private to avoid some other class to mess with our class, and normally public members are protected so that another class will not be able to mess too much with our class (well, that’s the theory, in practice you won’t see protection very often, and a lot of public members could be set private without any problem…).

Also, it is absolutely not recommended (and yet C# compiler authorize it…) to have a local variable having the exact same name as a member variable.
If you do that, then in your method you will access the local variable by default, but that may not be your intention, in long methods (more than one page of code) you may ‘forget’ that you’re using a local variable instead of the member one.

Using ‘m_’ (or just ‘_’) before the name of the members will solve the second problem, and help with the first.
I’m sure there are other ways to solve these 2 problems, just use the one you prefer.

Note that it also helps having the same way of coding in a project/company.
But it’s only a tiny part of that, to have coherent coding between the devs of the same company require a whole set of coding rules.

[exiguous]

Another point to consider is, that typing “m_” cleans up your intellisense a bit so you can better see members only and don’t have to look through all the “clutter”.
Saying that, I rarely use it and see it in Unity projects.

Shakespeare already wondered to “m_” or not to “m_” (or is my memory playing jokes here?). So I would say it’s a choice of preference. If you are used to it and apply it everywhere there is no harm in doing so. If you don’t use it no harm is done either. So just do what serves you best and be happy with it.

[Bunny83]

I don’t like polls where the only two options are the extremes of two sides. So I don’t participate in such polls ^^. Polls need more intermediate choices and at least a neutral. Not everything is black and white.

For example I have picked up the habit of using an “a” prefix for method arguments. This solves all potential problems with ambiguity with member variables or local variables. Personally I don’t like to read code like this:

void SomeMethod(int someVar)
{
    this.someVar = someVar;
}

A lot people do this all the time. So I like this much more:

void SomeMethod(int aSomeVar)
{
    someVar = aSomeVar;
}

I actually do use “m_” occationally but only for private member variables. Especially when you have several properties where you need to implement the backing field manually because the getter and setter requires extra code, it makes the naming much clearer. I’ve seen people naming the backing field something completely different from the property which in my opinion is far worse.