Member variables style questions

  • Thread starter Thread starter Richard Lewis Haggard
  • Start date Start date
R

Richard Lewis Haggard

What is the logic for dropping the C++ prepending of 'm_' from member
variables? Has there been a consensus developed on how to discriminate
between class members and automatic temp variables?
 
I still use m_ for my variables. Otherwise, you are right, that it is hard
to determine what has local or class scope.
 
What is the logic for dropping the C++ prepending of 'm_' from member
variables? Has there been a consensus developed on how to discriminate
between class members and automatic temp variables?
Click to expand...

Well, not everyone has dropped it. I don't use m_ at home, but I do at
work.

Personally, I think that methods should almost always be short enough
that it's blatantly obvious which variables are member variables and
which are local variables.

If you're comfortable using m_ though, there's nothing to stop you from
using that - and if you follow the guidelines of making all member
variables private, no-one who isn't reading your source code will ever
know anyway (unless they poke around with reflection).
 
And you can always obfuscate the code which makes this whole discussion mute
anyway. :)
 
It's nice to know that even if I am being something of a stuck in my ways
old fuddy duddy, at least I'm in good company.

Most of the programmers here at this new contract site come out of a VB
background and don't have a predilection towards a lot of things that those
of us who have spent time under the C++ code Nazis have internalized. They
think a lot of things I consider to be good practice to be over the top,
wicked over kill and downright pedantic. The only thing that stops me from
entering master programmer to young whippersnapper novice lecture mode is a
fear that they might be right. None the less, I shall strive to set a good
example and thereby show these poor benighted savages the error of their
ways.
 
It's nice to know that even if I am being something of a stuck in my ways
old fuddy duddy, at least I'm in good company.
Click to expand...

Well, bear in mind that there's a big difference between "m_..." and
Hungarian notation. It's perfectly possible to have either without the
other.
Most of the programmers here at this new contract site come out of a VB
background and don't have a predilection towards a lot of things that those
of us who have spent time under the C++ code Nazis have internalized. They
think a lot of things I consider to be good practice to be over the top,
wicked over kill and downright pedantic. The only thing that stops me from
entering master programmer to young whippersnapper novice lecture mode is a
fear that they might be right. None the less, I shall strive to set a good
example and thereby show these poor benighted savages the error of their
ways.
Click to expand...

You should also bear in mind that not everything which is a good idea
in C++ is a good idea in C# though. For instance, I've seen C# code
like this:

if (5==x)

That's harder to read (to most people, I believe) than

if (x==5)

However, in C++ it makes sense to use the first to prevent a typo of

if (x=5)

from slipping into the code. In C# the mistaken version doesn't compile
anyway.
 
i still use m_ prefix to all member variables that is used on property
declarations.

private readonly string m_fileName = string.Empty;
public string FileName{
get{ return m_fileName; }
}


this way i have an idea that the variable is used by the property and
nothing else. I just put underscrore (_) for private fields.
 
Richard Lewis Haggard said:
What is the logic for dropping the C++ prepending of 'm_' from member
variables? Has there been a consensus developed on how to discriminate
between class members and automatic temp variables?
Click to expand...

I used to do it but I have found that in practice the only place where I
seemded to need it regularly was in constructors and I now prefer to use

this.surname = surname

rather than

m_surname = surname

because it is more readable in the bulk of the code where fields and locals
or parameters rarely seem to want to clash.

P.S. There are some people out there who will mangle their parameter names
to avoid clashes with fields - Show them no mercy!


Another advantage of using "this" is that you get more out of intellisense.
 
What is the logic for dropping the C++ prepending of 'm_' from member variables?

Well, I never "dropped" it because I moved from C to C#, with a tour
through Java in between. C# is a whole new language, so I wouldn't
consider not following C++ practices in C# to be "dropping" anything.

That said, I have (reluctantly) adopted the convention of prepending
"_" to my member variables, not in order to distinguish them from
automatic variables (I prepend "this." to indicate that) but rather to
improve the workings of Intellisense and the debugger. It's a real
bummer in the debugger's locals window to have to scroll past dozens of
expensive-to-compute properties in order to get to the (no-cost) field
I want to see. The "_" puts all of the fields at the start of each
object's watch display, so I can see the object state first, and then
scroll for property values if I want to.

Plus, it solves the problem in Intellisense of picking the field by
accident instead of the property, or vice versa.
 
Bruce Wood said:
Well, I never "dropped" it because I moved from C to C#, with a tour
through Java in between. C# is a whole new language, so I wouldn't
consider not following C++ practices in C# to be "dropping" anything.

That said, I have (reluctantly) adopted the convention of prepending
"_" to my member variables, not in order to distinguish them from
automatic variables (I prepend "this." to indicate that) but rather to
improve the workings of Intellisense and the debugger. It's a real
bummer in the debugger's locals window to have to scroll past dozens of
expensive-to-compute properties in order to get to the (no-cost) field
I want to see.
Click to expand...

1) As a design guidline anything that is expensive to compute or is likely
to throw an exception should be a method rather than a property. The whole
point of properties is that they appear to be fields.

2) I have started using DebuggerBrowsableAttribute to suppress trivial
properties which simplifies things a bit.
The "_" puts all of the fields at the start of each
object's watch display, so I can see the object state first, and then
scroll for property values if I want to.

Plus, it solves the problem in Intellisense of picking the field by
accident instead of the property, or vice versa.
Click to expand...

I know what you mean but for some reason i find leading "_" particularly
jarring to read - more so than "m_".
 
Back
Top