To m_ or no to m_, that is the question...
I apologize for shocking your system by posting more than once a month - there are reasons for that, but I unfortunately can't get into them right now - but Keith added an interesting comment to my last post. He said:
Side Note: a bit disturbing you're using C++ naming conventions in C# though? :) No doubting your a ninja coder and I love your stuff, but seriously, bringing the m_ prefixing into C# is a bit of a "cant teach an old dog new tricks" thing.
This is pretty close to a "religious question", but since it's my blog, I'm always right (as codified in the "decree on Gunnerson infallibility of 1997"), so I'll take it on.
When I first started writing code, a lot of our samples were written without any way of indicating whether something was a field or not, and I wrote a considerable amount of code using that idiom. What I found was that when I went back and looked at my code later, I had to scroll around to find out where each variable came from, and that made understanding the code harder.
I toyed for a while with using just and underscore "_name", but I didn't like that. A single underline is a bit hard to pick up visually, and it seemed like I was inventing a different expression just to be different. So, I switched back to "m_", and I must say that I'm happy with the choice. The only place I don't like it is with events or other public fields, which are then named differently, but I'm willing to deal with that.
The only other place I use prefixes is on pointers, where I just use "p". Unsafe code is rare enough that I want to have an indicator of what's going on.
[Update: Another reason to use m_ is to make it easier to find your variable names in intellisense when you're working with controls, since there are roughly 4000 members in the average control class. I've also been using "c_" in the names of controls for the same reason]
So, what do you think, keeping in mind that if you disagree, you're wrong...
Comments
Anonymous
June 15, 2007
The comment has been removedAnonymous
June 15, 2007
I've never understood why some people refuse to write "m_" (a 2-character prefix) but are just fine with writing "this." (a FIVE-character prefix).Anonymous
June 15, 2007
The comment has been removedAnonymous
June 15, 2007
http://blogs.msdn.com/brada/articles/361363.aspx Section 2.6.Anonymous
June 15, 2007
Mike Dunn - Because m_ is in the variable name, this. or this-> is in the language and carries semantic meaning, like kfarmer mentions. Furthermore it allows you to omit it where it's clear without clarifying scope of the var. Personally, I like python convention with 'self' and '_foo'.Anonymous
June 15, 2007
I've written a lot of C# code, and I really don't understand the need to distinguish between member private fields, local variables, and parameters/arguments. I don't think it matters most of the time where the variable is declared, as long as it is known to be in scope, has a known meaning and type, etc. I like them all use the same naming convention -- it makes the code cleaner and makes it easy to move the definition of a variable between any of these three locations without refactoring. I specifically dislike prefixes like "m_" and "_" because they slow down typing and IntelliSense matching. They also look ugly and make the code look more cryptic when reading it later when maintaining the code.Anonymous
June 15, 2007
I go back and forth. Some days are "m_" days and others are not. I think it relates to how much database work I'm doing that day and whether I'm use to typeing the underscore. But at the end of the day, if I can read it and I can reasonably conclude that others can read it and it compiles, I'm good.Anonymous
June 15, 2007
Personally, I think _ is an abomination that doesn't belong in code, so I prefix member variables with "the". It reads well, allows me to speak about the code out loud without sounding like an idiot. I prefix arguments with a/an, and local variables have no prefix. "this." is just a bit too much to type.Anonymous
June 15, 2007
You don't happen to suffer from long methods and/or long classes, do you?Anonymous
June 15, 2007
Using the same m_ and c_ and like this approach.Anonymous
June 16, 2007
In C++ there is a rational for a prefix like (like "m_"). In the initializer list you cannot use "this" for scope resolution. So, to avoid having parameter name collisions with fields "m_" is used to delineate fields. C# was designed to not need the prefix.Anonymous
June 16, 2007
@bleroy: Brad reserves the right to be inconsistent, consistently :-)Anonymous
June 16, 2007
The comment has been removedAnonymous
June 16, 2007
The comment has been removedAnonymous
June 16, 2007
RE: CLS compliance. Only if the fields are public; which is a no-no...Anonymous
June 16, 2007
Thomas - not all compilers agree. Even still bar(bar) is horrible for readability.Anonymous
June 16, 2007
Peter - Sure, it's not the most readable, but for an init list I honestly don't care; There's no ambiguity present. As for compilers, I've used it with MSVC/GCC/Intel without issue for many years.Anonymous
June 16, 2007
I use _ rather than m_...it's one character less but I'm not really bothered with one or the other. Having said that as far as I'm concerned I must have a field prefixer, it's easier to see what's going on in the code; you can't rely on 'this.' as some fields are static. Also it stops mistakes where some locals can have the same name as a field and you don't realise it. Regards LeeAnonymous
June 16, 2007
The '' prefix has the advantage that intellisense lists all your private fields at before all other members, at the top of the list. I'm the only person I've met who likes to use both the '' prefix and the 'this.' qualifier on field references. This is because, after working on C# IntelliSense for a few years, I am very comfortable using its features. 'this._' is a powerful way of directing IntelliSense to get you what you want.Anonymous
June 16, 2007
Sorting in the class/member/intellisense list has to be the worst reason for prefixes.Anonymous
June 16, 2007
Just use "ClassName." on static members...Anonymous
June 16, 2007
I totally agree with you Peter. I can understand the use of “” to distinguish scope (if you need it, you need it). What I can’t understand is the “m”. What does “m_” stand for? (I already wrote about this, so I’m not going over that again - http://msmvps.com/blogs/paulomorgado/archive/2007/05/20/naming-conventions-for-c.aspx)´ I’m forced to use “m_” at work but I always qualify instance fields with “this.” and static fields with the type name. I’ve reviewed code where a developer changed the use of something from a class field to a local variable (keeping the “m_” prefixed name because it just started as a test) and was not understanding why the field was having its valued changed just inside that method. When I started qualifying all fields the bug surfaced immediately.Anonymous
June 17, 2007
jaybaz_MS, You're not alone in this world ;-). I both use _ prefix for private member variables and the this. qualifier on references to those fields. I think the _ prefix is the shortest most readable prefix for private fields that share the same name as the properties they most of the time belong too and 'this.' makes my code more readable by separating local from member variables.Anonymous
June 17, 2007
The comment has been removedAnonymous
June 17, 2007
The comment has been removedAnonymous
June 17, 2007
The comment has been removedAnonymous
June 17, 2007
The comment has been removedAnonymous
June 17, 2007
I used to use "m_", but after I started using FxCop I reverted to using "_" to prefix private variables. I don't like using camel casing for private vars and Pascal casing for public fields because it's too easy to transpose. Eg: private int myInt; public int MyInt... it's too easy to put MyInt in the wrong place. _myInt is much harder to stuff up. Plus, IMO it makes it easier to spot private vars when scanning code.Anonymous
June 17, 2007
We use "my" for this. It's the same length as "m_", it's a real word, and it expresses the ownership relationship between the class and the member variable. We didn't want to use Hungarian when we moved to C# but we came to the conclusion that there's a difference between including type information (not a good idea any more) and what could be described as variable meta-information - like it how it is meant to be stored or used. For us, indicating whether a variable is a member variable fell into the realm of useful meta-information. We wound up picking a short list of approved lower-case prefixes for variables. Our aims were to give some useful meta-information, to comply with the camel-case recommendation of the Framework Design Guidelines and FxCop, and to use meaningful words to do it. Oh, and just in case it wasn't clearly implied by that last point, we wanted to completely eliminate underscores! At least one member of the team went into convulsions at the very sight of an underscore ;-) Here's our list of prefixes: const: a constant my: a member variable of a class a (or an): a local variable used to access members of a collection loop: a local variable that will be used to control a loop the: any other local variable in: a parameter that is only passed in to the method out: a parameter that will hold data inserted by the method io: a parameter that performs both "in" and "out" roles In practice, I'm not sure if we've ever used "out" or "io", but the others are used consistently in our code and do seem to prove useful.Anonymous
June 17, 2007
Even though I'm obviously wrong, my vote goes to this.Public and _PrivateAnonymous
June 18, 2007
The comment has been removedAnonymous
June 18, 2007
The comment has been removedAnonymous
June 18, 2007
I like to use mMyVariableName, _ is no good because then your classes aren't CLS compliant if you use a protected variable. m_ is too much to type IMO.Anonymous
June 18, 2007
I'm OK with '' or "m"... See: In praise of '_' http://ademiller.spaces.live.com/blog/cns!769B86D17666DFEF!237.entryAnonymous
June 18, 2007
I use the 'variable' for all Global variables and just 'variable' when in methods. The '' allows me to quickly see if the variable is global!Anonymous
June 18, 2007
Foi lançada um discução no blog do Eric Gunnerson acerca do assunto "Prefixar com m_ ou não prefixarAnonymous
June 18, 2007
Actually, the IDE should show public, private, and local variables in separate fonts. Const or static identifiers would be distinctive as well, and globals, in languages that have them, would be displayed using the blink tag.Anonymous
June 19, 2007
Sure are a lot of people who have comments without any intelligence behind there statements. Personal preference for your own being don't count. What works will with programs and others that need to review / examine your writings is the only thing that matters.Anonymous
June 19, 2007
How many naming conventions were violated here? http://msdn2.microsoft.com/1h3cat6t.aspxAnonymous
June 20, 2007
I hate underscores, since they're actually one character for the cost of 2 keystrokes. So I use just an "m": mVariableName. As was suggested above, I use "c" for constants. Add to this, for static fields, an "s".Anonymous
June 20, 2007
I like Joseph Newcomer's comments on the topic of "m_". He describes the use of "m_" merely as a compulsion. And "...if using "m_" was the only correct and sensible way to designate member variables, don't you think Bjarne Stroustrup would have designed the language that way and no other?"Anonymous
June 20, 2007
I fully agree with Paulo and Peter because the prefix normally shows that the code is not really readable enough, and so the prefix appears to save the day. I normally use in private fields the name using camelCasing, and when i call it normally i use because this.<fieldname>. As for the m_ or , i normally don't use none of them, but the _ doesn't shock me because it has the nice this of putting all that fields first in the intellicense, but i don't like the m, because i don't know why m_ and and not v_, i_ or anything else in the alphabet. If this m_ is really the a naming convension then i agree with Paulo, the next stop will be Hungarian notation again, and honestly i hate it.Anonymous
June 20, 2007
I fully agree with Paulo and Peter because the prefix normally shows that the code is not really readable enough, and so the prefix appears to save the day. I normally use in private fields the name using camelCasing, and when i call it normally i use this.<fieldname>. As for the m_ or , i normally don't use none of them, but the _ doesn't shock me because it has the nice this of putting all that fields first in the intellicense, but i don't like the m, because i don't know why m_ and and not v_, i_ or anything else in the alphabet. If this m_ is really the a naming convension then i agree with Paulo, the next stop will be Hungarian notation again, and honestly i hate it.Anonymous
July 02, 2007
When we started using C# at work we first tried without prefix. This caused hard to spot errors in our code when the parameter name was spelled the same as the field name (especially when setting a property value in a constructor). We considered the use of this., but found that the problem was that the compiler does not enforce consistent usage. If the field has a prefix, then the compiler forces you to use it. To ensure consistency we implemented an fxcop-rule to enforce the m_ prefix. Trygve