Reputation: 86185
somebody like to use m*, someone like to use _*, is there any guideline of this?
Upvotes: 0
Views: 179
Reputation: 1503869
Yes, there are guidelines around this. You'll often find at least one in the company you work for, if it's an ISV. Sometimes more than one. Chances are it won't be adhered to consistently, unless you've got a good regime of code review and everyone understands the naming convention thoroughly.
There's no one standard naming convention for this - simply because the benefits of a worldlwide convention don't exist for private members in the way that they do for public members.
If I've got to use libraries from 5 different companies, it really, really helps me if they're consistent in terms of naming types, methods, even parameters. I couldn't care less what naming convention they use for their private members: whatever lets them write code as effectively as possible, basically.
Personally, I don't use any kind of prefix for private variables... but I've worked in companies which use _
, and I've worked in companies which use m_
or s_
.
Upvotes: 3
Reputation: 4841
The Microsoft recommendation is to use a leading underscore like: _myField
.
But even they don't stick that convention.
Personally, I use a leading undrscore so that I don't have to qualify my variable names with this.
and because it's easier to tell them apart from arguments.
Upvotes: 0
Reputation: 944
I've traditionally used camel-cased prefixed with an underscore (e.g., _firstName
) but more and more I'm moving to automatic properties b/c there's less code clutter and 9 times out of 10 I don't need a private field.
public string Firstname { get; set; }
Upvotes: 5
Reputation: 210765
Like you said, it's a convention. I believe people from a C++ background use the m_* notation often, but I myself prefer the _* notation. There's no fixed rule though; consistency is the key. The one rule I always follow is making sure I use the this
pointer.
Upvotes: 1