To "m_" or not to "m_"?
-
Vagif Abilov wrote:
I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think?
I think these areguments are valid. However, in C# is isn't so common to use "m_". The coding standards at my work don't allow it so I don't use it any more.
Vagif Abilov wrote:
When you don't use prefix with memeber variables, you have more changes to mix three different things
Been there, done that! And it can be a pain to debug because often you just don't see for a while the difference between "Customer" and "customer".
My: Blog | Photos "Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious
Colin Angus Mackay wrote:
I think these areguments are valid. However, in C# is isn't so common to use "m_". The coding standards at my work don't allow it so I don't use it any more.
Someone (not the boss) at work tried to start a coding standard that disallow "m_", I kept using it in my code, they gave up once they realized how much existing code already had "m_". ;) The main problem, I think, is that if you are looking at someone else's code that does not use "m_", it can be very hard to determine which variables are member variables, especially when the method is long and there is a long chain of inheritance for the class.[
My articles and software tools
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
I've started to _ now where my early C# code didn't bother with any prefix. I just used this. when I wanted to use a member variable. m_ was fine for working with MFC as thats what the class libraries used as their naming convention and it made sense to make my own code fit the convention. Michael CP Blog [^] Development Blog [^]
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? having seen to many "religious" debates about this, i am sticking with the following answer :) this is a short, sensible and valid reason for doing something. the amount of work required is small, and the potential benifits seem quite large (think of the time saved debugging / fixing problems). this makes it a good argument :) zen is the art of being at one with the two'ness
-
ditch the underscore "_" and use just "m" or use "my" for parameters prefix with "p"
ahz wrote:
for parameters prefix with "p"
X| 1. What makes distinguishing parameters from local variables so important that you have to mangle their names? 2. What happens when you have a local variable named, "price", or "prev"? My motto is keep the code simple and easy to read, although I don't mind "m_" prefix for fields. Alvaro
I cannot take anything the Bush administration does seriously. The corruption, the cynical disregard for humanity, the cronyism and incompetence, all wrapped in a slimey flag of ultra-marketed nationalism repulses me. -- consdubya from fark.com.
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
I loathe all: m m_ _
Vagif Abilov wrote:
When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable.
- Don't use argument names that can be confused with field names 2) I have never been confused between a property and field using Intellisense. Maybe because my fields are protected/private. Marc My website Traceract Understanding Simple Data Binding Diary Of A CEO - Preface
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
Not only is it against the Framework Guidelines to do so, it just looks ugly. If you're using IntelliSense, then you should be able to distinguish fairly easily whether something is a field or a property. In addition to that, the visual cue of the PascalCase vs the camelCase is pretty significant if you use an appropriate font.
Picture a huge catholic cathedral. In it there's many people, including a gregorian monk choir. You know, those who sing beautifully. Then they start singing, in latin, as they always do: "Ad hominem..." -Jörgen Sigvardsson
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
Vagif Abilov wrote:
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#.
That's funny I did as well and I'm only now breaking myself of the habit and using the _underscore instead. I name private member variables with an underscore and keep the case the same as the public property. So I do this:
private int _InfamousI public int InfamousI { get{ return _InfamousI;} }The m_ is just an extra character to type as far as I can tell and most .net style guides recommend using just the underscore.
"Hello, hello, what's all this shouting, we'll have no trouble here! This is a Local Shop for Local People, there's nothing for you here!" -Edward Tattsyrup
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
m_ works and I always use it, makes the code easier to read :) - Anders
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
I prefer _varName, dropping the m. I tried just using this.varName, but it requires my own diligence when using it. Allowing for errors between class private variables and parameters passed into a procedure when I forget to use the this keyword.
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
Vagif Abilov wrote:
When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think?
If your code needs to be CLSCompliant, then m_ is a great way to ensure
protectedfields are named differently from their corresponding properties. (Then again, properties almost eliminate the need for declaring fields asprotected, but that's a different argument.) I normally use m_ for my own personal class libraries (such as the ones I've published here). Here at work I don't use it, since no one else does. Consistency is more important. The reality is that for small and simple enough classes the m_ prefix is overkill. My 2 cents. Regards, Alvaro
I cannot take anything the Bush administration does seriously. The corruption, the cynical disregard for humanity, the cronyism and incompetence, all wrapped in a slimey flag of ultra-marketed nationalism repulses me. -- consdubya from fark.com.
-
*shudder* I cant abide the MyCutiePieLittleObject style. Are you a VB programmer? :P Personaly I keep the manly underscore for private fields and ditch the hungarian. Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
No, I'm not a VB programmer. I detest VB. Well, I wouldn't use "My" either, but I have used "my" at a previous place of employment, but I prefer the prefix "m" or no prefix at all. underscore is bad, captilization is good. m_member --> NO!!! mMember --> ahh, yes member --> Even better!
-
ahz wrote:
for parameters prefix with "p"
X| 1. What makes distinguishing parameters from local variables so important that you have to mangle their names? 2. What happens when you have a local variable named, "price", or "prev"? My motto is keep the code simple and easy to read, although I don't mind "m_" prefix for fields. Alvaro
I cannot take anything the Bush administration does seriously. The corruption, the cynical disregard for humanity, the cronyism and incompetence, all wrapped in a slimey flag of ultra-marketed nationalism repulses me. -- consdubya from fark.com.
Alvaro Mendez wrote:
distinguishing parameters
if you have local variables that are similar in usage or type that are used to compute an intermediate result for the parameter, especially an out parameter.
Alvaro Mendez wrote:
What happens when you have a local variable named, "price", or "prev"?
if parameters are named "pPrice" or "pPrev" that distinguishes them from the "price" or "prev" local variables or data members. I agree with your statement/motto to keep the code simple and easy to read. That acutally supports the idea of using prefixes in certain cases. The basic idea is that if you have data members of your class or local variables that have the same names as the parameters, then how do you distingish them without going to extremes or renaming the parameters/variables to something like "temp1", "temp2", "param1", "param2" (which convey no meaning whatever)? Usage of prefixes then seems more reasonable. I have to say though I have never actually used the "p" prefix myself, but I have seen others do it.
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
I always ditch the "_" and keep the "m". I also always make members accessible by Properties so you would rarely see this.mCustomerName. In VB my classes look like this... ============================== Private mCustomerName As String Property CustomerName As String Get return mCustomerName End Get Set(value As String) mCustomerName = value End Set End Property ============================== and in referencing the member I would use this.CustomerName. Anything wrong with this approach?
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
Nothing hungarian about the "m_" prefix, other than the mere fact that it is a prefix. Hungarian notation denotes logical type (not storage type, however), whereas the "m_" prefix denotes scope. I have for years used "m_" for module-scope variables, and "p_" for parameters. Using "this." for class member variables would certainly serve the same purpose as "m_", but, as others have stated, relies upon the discipline of the programmer to enforce, a practice that, in my experience, is nearly always a mistake.
-
I always used to use "m_fooname," but at my new employer the coding standard says just "_variableName", no M. So, I've switched to that, even for my personal stuff.
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
-
*shudder* I cant abide the MyCutiePieLittleObject style. Are you a VB programmer? :P Personaly I keep the manly underscore for private fields and ditch the hungarian. Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
Yep, I find myself using just the _ for private stuff. Handy thing is, all the privates are then grouped together in the IDE's suggestions as well. No confusing something with Something as well when my eyes are tired.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
But that violates the C++ standard. You can't have identifiers starting with '_'. Those are reserved. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Thought that was "__" not "_"? Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
-
Thought that was "__" not "_"? Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
__ can not appear anywhere in an identifier. _ can not be the first character of an identifier. I don't have the specific rules, but those cases are reserved for the compiler vendor and the language. Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
In case you write code in C#, do you use prefix class member variables with "m_"? I inherited this habit from C++, and in the beginning I used it also in C#. However, later I decided that it is better to use built-in language features rather, so I started using "this.". Example: (old habit) string m_customerName; ... m_customerName = "Bill"; (new habit) string customerName; ... this.customerName = "Bill"; I find it more natural to C# and corresponding to .NET naming convention guidelines. I also find prefix "m_" a little Hungurian :-) However, Juval Lowy in his excellent C# coding guidelines (from his book "Programming .NET Components) suggests always prefix private member variables with "m_". My colleague justified this with the following arguments: When you don't use prefix with memeber variables, you have more changes to mix three different things: method argument name, member variable and property. Properties are often named like variables but have capitalized first letter. When using Intellisence, it is easy to confuse property with the variable. I find this arguments to be practical, probably sufficient to start using "m_" again. But what do you think? Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.
I agree with your original reasoning and did exactly the same thing when I moved to C#. One problem with "always prefix[ing] private member variables with "m_"" is that they may not always be private. If you change the member variable to protected, you now have to refactor your code. (This is essentially the same reason I've always opposed Hungarian notation in C++ for anything but "p" for pointers [knowing something is a pointer is rather critical in C++].) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke