Using a Prefix on Non-Public Fields

I don't know anyone who uses a 'm_' to pre开发者_开发知识库fix non-public fields (myself included), but I am aware of three reasons why it should be done:

1. The CLR specification insists that property names and corresponding fields not differ merely by letter casing. Some languages are case-insensitive. “_” could be used, but “m_” is preferred because names should start with alphabetic characters. (This comes from coding standards suggested by Dan Rigsby)
2. A mere “_” prefix is not CLI compliant, whereas “m_” is CLI compliant.
3. Intellisense, at least in WPF as of VS 2008, does not distinguish between types defined in XAML and types defined in code-behind. A 'm_' used in the code behind would resolve the issue.

My question is this: would you (yes, you!) be able to accept this as a new standard on projects you are currently working on, given the reasons stated, or would you still just lose your mind in unbridled hatred of the idea?

p.s. Please don't tell me "Hungarian" is bad, since this suggestion - in isolation - really has no connection with Hungarian.

Most people I know (including myself) just use _ as a prefix for non public fields. It's shorter to type, and it makes the fields appear all together in intellisense. I also find it more readable than m_

This question has been asked on SO many times, but once again, it comes down to personal preference and, as long as you are consistent, you're not going to have any problems with either approach.

As far as I know, most C# coding standards call for lower case member variable names with no prefix. Personally, I don't like this approach because your member variables tend to clash with method parameters, so you constantly have to qualify them with 'this'.

I use a single underscore before the name of member variables, but I am sure there are many people out there who don't like that either. It boils down to being consistent throughout the code base.

The CLS not CLR specification insists that public and protected members not differ only by case. It's important to be aware of the fact that there is no need to make your types CLS-compliant unless you plan on using them in other projects that span multiple languages. Even then, if this is an internal project there may not be a need to follow all of the CLS guidelines.

In any case, this applies only to members that are potentially visible outside of the declaring assembly (in other words, private and internal members are exempt), this suggestion is not relevant to non-public fields.

That being said, the concept of naming conventions has been debated since we were able to name variables. Personally, no, I do not like the idea of prefixing variables with m_, but that's a personal preference.

Yes. It is important that all programmers accept the standards of the projects they are working on - it is a good sign that management is insisting on standards, whether the individual agrees with them or not.

Personally, I think prefixing with "m_" is a waste of a keystroke, but if it's in the standards then that's what I'll adhere to.

If I was writing the standards, I would specify that "_" should be used as a prefix to non-public fields.