To "m_" or not to "m_"?
-
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
-
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.
-
Alsvha wrote:
We also signify the type of the variable by a 3 letter abbriviation such as for exampel mStrSomeName.
Isn't that adding a lot of work when you change types for the variable.
It is adding some additional work, yes, but not much. But if you change the type definition first, it is easy to find the remainder usages of this variable, and with some copy/past work it is quickly done. The benefit when reading the code is increased in my personal opinion. --------------------------- 127.0.0.1 - Sweet 127.0.0.1
-
Colin Angus Mackay wrote:
Sounds like it is time to refactor if the method is long.
And using "m_" would make refactoring of a long method easier. :)[
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.
Everyone knows the "_" underscore died back in Assembler, time to move on ;) "this." works perfectly fine when needed! Guess that is why they put it in ;) Rocky <>< Latest Post: SQL Server 2005, Major Enhancements! Blog: www.RockyMoore.com/TheCoder/[^]