Joe Stagner blogged today about some basic coding guidelines one of which was to avoid using any sort of prefix for member variables (including the underscore). I personally prefer to use the underscore prefix on private
member fields and mainly so they would be easily identifiable from local variables. But Joe’s guidelines suggested a workaround recommending that we use this
to indicate a member variable.
private int _age; void Foo() { int age; //... if(age > _age) // <-- My way { //... } }
private int age; void Foo() { int age; //... if(age > this.age) // <-- Joe's recommendation { //... } }
While I did think that was a fair approach, I am still not convinced it’s fully alright since the onus is on the coder to remember to do this – there’s nothing stopping him from forgetting to prefix this
for member fields. So for the time being I am going to continue using underscore for private members.
Trouble with that is when you have properties. Now you would have to really creativity name your private fields
But properties would always use Pascal casing. So they would never clash with a private field, would they?
In my example, if there was a property it would be
Age
Yes, but Pascal case has no sense in VB.NET therefore in order to mantain compatibility rules I prefer using “m_” as prefix of private members.
I use the underscore approach too for the exact same reason. I tried doing the “this.” approach, but too many opportunities for coder errors if you ask me.
I can’t stand code that uses “this.” all over the place. It’s syntactically redundant and gives me the impression that the author doesn’t understand how member variables work.
I also get a chuckle when I see someone decry a one-character prefix, but have no problem with using a five-character prefix instead.
It will be lazy to admit this, but an advantage to using “this.” is that you get Intellisense when you are typing it. I often do this.
Does Ctrl+Space not bring up the Intellisense list in C#?
yes, and in VB.NET is automatic, you just write “m_” and the intellisense suggest you all private fields defined with prefix “m_”
Only use of this pointer I came across is to access the object in called methods like returning reference to object from the method e.g. overloaded assignment operator.
m_ is my preferred naming convention for attributes. It is clean and instantly recognizable.
I’m with Joe Stagner on this point … no prefix decoration on class members. It yields the very cleanest publication of the class. For years I’ve prefixed all parameters and locals with undersore which eradicates the possibility of any name conflicts.
use g_ for global, m_ local
I agree with the blogger. _ for private fields!
Why use prefixes, _ in particular? Microsoft specifically advice against it! Also, why use a prefix for private fields specifically, when you don’t have a prefix for constants. Or for statics. Or for readonlies?
For those who call “this.” a five character prefix: The difference and beauty of “this.” is that you don’t have to use it unless there is a conflict.
For those who think “this.” is hard to remember: Do you think _ is any easier? (As in universally easier, not just easier because it is what you’re used to?)
Soprano and allows to perform virtually any operation possible on the Nepomuk RDF database. ,
I agree with the blogger. One needs to come up with creative names for parameters when using static classes since using “this” is not possible
Microsoft recommends not using underscore as a prefix. I think that when it is a matter of taste it is always better to stick with the standards or recommendations.
Still thinks it’s weird… Microsoft can recommend anything they want but as long as I see their internal developers use the prefix “_” for the past 10 years and are still using it to this day then it’s just confusing.
Whatever Microsoft is saying it IS a standard and a recommendation by their employees. It’s a standard and recommendation by the majority of the community. Even Resharper does it by default.
And I can understand why they use it, it’s easy, it’s useful and next to the “I” prefix for interfaces there are no prefixes so no cluttering. I can understand the hungarian notation being obsolute in the new age of software development. But that doesn’t mean that it’s evil enough to discourage using 2 useful prefixes.