everyone said the "underscore, no underscore" debate is purely philosophical and user preference driven but with intelli-sense having the underscore allows you to differentiate your member variables from your local variable very easily and thus giving you a concrete benefit
is there any counter argument to this benefit of having underscores to all member variables?
Yes - for some people it reduces readability. I believe different people read in different ways (some internally vocalise and others don't, for instance). For some people (myself included) underscores interrupt the "flow" of code when I'm reading it.
I'd argue that if you're having difficulties telling local and instance variables apart, then quite possibly either your methods are too big or your class is doing too much. That's not always going to be the case of course, but I don't tend to find it a problem at all with short classes/methods.
If it's just the intellisense you want you can always get it by typing "this.".
OK, it's 4 more chars than "_", but the intellisense will then bring up your members for you.
If you use underscores and your team uses underscores then keep using them. Others will use "m_", others might have other ideas. I use StyleCop and on my team the debate is over, we use "this." and Hungarian style or underscore prefixes are not used. And we just don't worry about it anymore.
[Edit] This is not a criticism of your question - it's a valid question and it's worth asking - but this debate wastes way too much time on dev projects. Even though I don't like everying about StyleCop I willingly use it as it cuts out this type of debate. Seriously, I've been in hour long meetings where this kind of discussion occupies a whole dev team. Crazy. Like I say, your question is valid but please don't waste your own time agonising over this, it's not worth it:-)
Using underscore is just one way of achieving that effect. The important thing is to be consistent about it.
The underscore can be seen as a form of hungarian notation*, but the prefix is a "magical character" instead of something that has a meaning.
If you want something that says more about what the prefix is for, you would use a prefix like member or mbr or m. Sometimes the prefix m_ is used, but then the underscore is used as a separator rather than a part of the prefix, and the naming recommendations for .NET says that it shouldn't be used as a separator.
Personally I have come to like the underscore for member variables, eventhough it's a prefix with a hidden meaning. It doesn't clutter up the names as much as any other prefix would.
And as always, it's more important to pick a standard and stick to it, than which standard it is that you actually pick.
* Hungarian notaition has mostly come to be used to specify data type in weakly typed languages like VBScript, but the original intention was to specify other properties of variables, so using it for member variables is more along the original intentions.
Using this. everywhere reduces readability in my opinion. Underscore prefixes for private class fields is perfectly acceptable. Its hardly Hungarian which is a truly awful naming convention and on the intellisense front typing _ plus a letter is an extremely quick way to bring up your list. I use CSLA.NET and a lot of the BO examples use the underscore convention and I continue to use it in all my work. Don't let the old school ex C++ and C developers scare you into thinking it isn't good practice - .NET doesn't suffer the same issues. A good example is passing arguments in constructors:
public MyObject(int field1, int field2, int field3)
{
_field1 = field1;
_field2 = field2;
_field3 = field3;
}
In my opinion is a lot more readable than
public MyObject(int field1, int field2, int field3)
{
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
}
But it is personal taste and as has been said elsewhere consistency is the most important issue.
It really doesn't matter what naming convention you choose as long as you use it in whole project.
