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.
-
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.
ditch the underscore "_" and use just "m" or use "my" for parameters prefix with "p"
-
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.
At work we use "m" to signifiy member, but not m_ which suits me good. I hate underscores in names other then constants. Don't know why. We also signify the type of the variable by a 3 letter abbriviation such as for exampel mStrSomeName. Using "m" is in my view a nice quick way to know if you are dealing with a member variable/object.. "this." I only use for methodcalls and such, never for variables. --------------------------- 127.0.0.1 - Sweet 127.0.0.1
-
ditch the underscore "_" and use just "m" or use "my" for parameters prefix with "p"
*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)
-
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.
-
At work we use "m" to signifiy member, but not m_ which suits me good. I hate underscores in names other then constants. Don't know why. We also signify the type of the variable by a 3 letter abbriviation such as for exampel mStrSomeName. Using "m" is in my view a nice quick way to know if you are dealing with a member variable/object.. "this." I only use for methodcalls and such, never for variables. --------------------------- 127.0.0.1 - Sweet 127.0.0.1
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.
-
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 use "m_" prefix for member variables, which, in my opinion, is very helpful when you are using the variables in member functions - one will not confuse between passed parameters(which I prefix with "param_") or local variables(which have no such prefix).
Vagif Abilov wrote:
I also find prefix "m_" a little Hungurian
Yes, although it IS a bit Hungarian, but the amount of benifit you get with this little effort is justified when you are debugging someone else's written code. "Do first things first, and second things not at all." — Peter Drucker.
-
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:
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
-
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 [^]
-
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.
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
-
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.