About conventions : "m_"

  • Thread starter Thread starter Guest
  • Start date Start date
Craig Kenisston said:
I've notice that some Microsoft's code, uses the "m_" convention to refer to
private member fields.
Check this :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;326080
http://support.microsoft.com/default.aspx?scid=kb;EN-US;326176
http://support.microsoft.com/default.aspx?scid=kb;EN-US;326145

I read the dotnet guidelines, and I don't recall the "m_" convention was
accepted.

Is Microsoft violating its own code rules ?
Click to expand...

I think so.

I've seen other instances of convention violation in .NET sample code
in MSDN, too:

- Using '_' as a prefix for member variable names.
- Using capitals and underscores for constant names -
THIS_IS_A_CONSTANT.

Personally, I don't use a prefix for member variable names in C#/.NET.
I used to in Delphi/VCL and C++/MFC, though.
 
I use the "m_" just because they are private, you don't see it when you use
my class, don't you? And I did that because I need a clue to make the
difference between a parameter and private variable, and I don't like to use
"this" all the time to access the private data.

Best regards,
Relu
 
I think you are right, they are inconsistent:

"Do not apply a prefix to field names or static field names." - bottom of
http://tinyurl.com/519n

Personally I think the readability gained by prefixes-on-fields is worth the
pain (if you can call typing "m_" pain). Some people put "this." on front
of all members usages, but the compiler won't tell you if you forget one.
After trying "_" for a while, I still prefer "m_", cause it stands out
better.
 
Note that preceding instance variable names with "_" will make your class
non-CLS-compliant. If your code is going to stay in-house, that might not be
a problem.

I still pine for C++, and am accustomed to typing "m_", but it means I have
to type two extra characters to get code completion to work, and for the '_'
I have to move my right hand out of typing position. Not good! So I *do*
type "this.", which Java programmers find perfectly natural when they want
to distinguish between a parameter and an instance variable.
 
Hey, how about this one.

Regarding events and inheritance, several places state that inherited
classes should override OnEventName() rather than listen to the base class's
events... but when you add a new form guess what the IDE-generated code
does.
 
How does that matter if we're only talking about *private* instance
variables?
 
Back
Top