在 C# 中，引用类中成员属性的普遍接受的方式是什么？
已通读 MSDN 命名指南，但找不到明确的答案，除此之外，您通常应该尽量避免使用下划线。 假设我有以下内容：
public class Employee
{
private string m_name; //to store property value called Name
public string Name
{
get { return m_name; }
set { m_name = value; }
}
public void ConvertNameToUpper()
{
//by convention should you use this
return m_name.ToUpper();
//or this
return Name.ToUpper();
}
}
上面 m_name 的正确命名约定是什么？ 例如，在我继承的代码中，我通常会看到：
- m_name
- _name
- name
- myName 或其他一些随机标识符
哪一个（或另一个）是最普遍接受的？
作为后续，在类的方法中，您引用内部（私有）标识符还是公共属性访问器？
Have read through the MSDN naming guidelines and could not find a clear answer, other than that you should try to avoid underscores in general. Let's say I have the following:
public class Employee
{
private string m_name; //to store property value called Name
public string Name
{
get { return m_name; }
set { m_name = value; }
}
public void ConvertNameToUpper()
{
//by convention should you use this
return m_name.ToUpper();
//or this
return Name.ToUpper();
}
}
What is the proper naming convention for m_name in the above? For example, in code I inherit I commonly see:
- m_name
- _name
- name
- myName or some other random identifier
Which one (or another) is most commonly accepted?
As a follow-up, in the methods of the class, do you refer to the internal (private) identifier or to the public property accessor?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
首先，我和我共事过的许多其他人已经不再使用私有成员的前缀“m_”。 接下来，每当我在类中引用私有成员时，我通常会使用“this”一词，如“this.privateMemberVariableName”。 使用它足以区分该变量不是局部变量或作为方法内参数传递的变量。
如果公共属性名称包含的逻辑不仅仅是引用私有成员变量，例如实例化连接或将属性值保存在视图状态中，我会引用公共属性名称。
First of all, I, and many others I have worked with have done away with the use of prefixing private members with "m_". Next, whenever I refer to the private member within the class, I usually use the word this as in "this.privateMemberVariableName". Using this is enough to distinguish that the variable is not a local variable or a variable passed as a parameter within the method.
I do refer to the public property name if it contains logic that is other than just referring to the private member variable, such instancing a connection or saving the property value in a view state.
框架设计指南 指出您不应在变量前添加 _ 前缀- 你应该只使用小写字母作为变量名称，我相信《Code Complete》第二版说你不应该在变量前面加上 m_ 前缀。
The framework Design guidelines book says that you shouldn't prefix your variables with _ - you should just use a lower case for the name of the variable, and Code Complete 2nd edition I believe says you shouldn't prefix your variables with m_.
我认为，无论您使用什么命名约定，最重要的是保持一致。
我的意思是，如果您选择命名私有成员，例如 _name ，那么始终这样做，而不是一次使用 _name ，另一次使用 m_name 。
我个人使用下划线前缀约定。 （原因之一是因为我使用NHibernate，并且NHibernate有一个'field.camelcase-underscore'访问策略。
对于你的另一个问题：
这取决于您想做什么。
您的属性是否包含额外的逻辑，您是否希望在引用它时执行该逻辑？ 然后使用该属性。 您不想执行逻辑吗？ 使用字段。
Eric Lippert 写了一篇帖子 在他的博客上对此进行了讨论。
对于您的后续行动：这一切都取决于具体情况。
如果您的属性包含一些附加逻辑，并且您不想在从类内部访问时执行该附加逻辑，则使用支持字段...
I think that, whatever naming convention you use, the most important thing is that you stay consistent.
I mean, if you choose to name private members like _name , then always do it like this instead of once using _name, and the other time m_name.
I personally use the underscore-prefix convention. (one of the reasons is because I use NHibernate, and NHibernate has a 'field.camelcase-underscore' access strategy.
For your other question:
It depends on what you want to do.
Does your property contain extra logic, and do you want this logic to be executed when you refer it ? Then use the property. You don't want to execute the logic ? Use the field.
Eric Lippert has written a post regarding this on his weblog.
For your folluw-up: it all depends on the situation.
If your property contains some additional logic, and you don't want to execute that additional logic when accessed from within the class, then use the backing field ...
首先 - 对于简单的获取/设置情况，我建议您使用自动实现的属性。 如果这样做，编译器将生成基础变量，并且您仅引用属性本身。
除此之外，我建议您选择上述之一或类似的内容并坚持下去。 我工作的公司使用 vName，其中“v”表示这是属性的值。
First of all - for the simple get/set cases I would recommend that you use automatically implemented properties. If you do that the compiler will generate the underlying variable, and you only reference the property itself.
Other than that, I suggest you pick one of the above or anything similar and just stick to that. The company I work for uses vName where the "v" indicates that this is the value of the property.
我使用 Style Cop 在你的代码上强制执行一些样式。 我发现这非常有用，我的所有团队成员也都使用它。
虽然关于 Style Cop 的使用有很多讨论，但我建议的一件事是，如果您使用 Style Cop，请启用所有样式。 这样，当您在用户之间共享时，事情就会变得容易得多。
这强制的一件事是你不能用下划线命名你的私有字段。 因此，我通常在编写私有字段时使用驼峰命名法，然后使用 PascalCase 命名公共属性：
Style Cop 还强制使用
this.，这使得内容更容易阅读。I use Style Cop which enforces some styles on your code. I find this very useful and all my team members also use this.
While there are great discussions around the use of Style Cop, one thing I would suggest is that if you use Style Cop that is to leave all styles enabled. This way when you share between users it makes things a lot easier.
One of the things this inforces is that you can not name your private fields with underscores. So I generally use camelCase when writing private fields and then PascalCase for public Properties:
Style Cop also enforces the use of
this.which makes things a lot easier to read.我在示例代码中看到的最常见的是简单的 _ 前缀。
然而，真正重要的是团队同意标准是什么并坚持它。
The most common one I've seen in example code is a simple _ prefix.
However, what really matters is that the team agrees what the standard is and sticks to it.
如果您不能像 Brian Rasmussen 建议的那样使用自动实现的属性，并且您必须有一个私有成员，那么我建议使用下划线前缀 _name。
在智能感知中，一个项目是参数、本地成员还是私有成员并不是立即显而易见的，因为它们都具有相同的符号（蓝色立方体）。 但是，如果您将光标移动到特定项目，则工具提示会告诉您它是其中的哪一个。
我发现下划线前缀是一种方便的视觉辅助工具，无需移动光标即可立即明显看出它是私有成员。
If you can't use an automatically implemented property as Brian Rasmussen suggest and you have to have a private member, then I would recommned the underscore prefix, _name.
In intellisense, it's not immediately obvious whether an item is a parameter, local or private member as they all have the same symbol (blue cube). If, however, you move cursor to a particular item then the tooltip tells you which of these it is.
I find the underscore prefix is a handy visual aid which makes it immediately obvious that it is a private member without having to move the cursor.
我曾经非常反对“_”前缀，但当您想要快速访问成员字段而无需键入许多字母时，它对于智能感知确实很有用。
I used to be very against the '_' prefix, but it really is useful with intellisense, when you want to quickly access a member field without having to type many letters.
一方面我同意你应该使用公司标准，另一方面我会尽力遵守行业标准。
On one hand I agree you should use company standards on the other hand I would try to adhere to industry standards.
我会回应之前的答案，因为您应该坚持您的团队使用的方案，或者如果您不在团队中，请与您使用的任何方案保持一致。
就我个人而言，我使用下划线前缀，因为我发现它给了我一个很好的视觉提示。
I would echo previous answers in that you should stick with a scheme that your team uses, or if you are not in a team, be consistent with whatever you do use.
Personally, I use the the underscore prefix as I find it gives me a good visual cue.
我认为普遍接受的命名约定只是为了使名称有意义（并且代码干净简单）。 在我看来，如果我的代码中的标识符出于任何原因需要视觉提示，那么它就太复杂了，而且名称通常不完全准确。
我曾经编写过需要手册才能阅读的代码...“m”表示类级别，“p”表示参数等。命名约定的开发是为了使代码更易于阅读，但最终只是做了相反，因为开发人员暗示“好的”命名约定意味着可读的代码。
只要确保丹尼斯·格林（前亚利桑那红雀队教练）这句话适用于您的标识符：“他们就是我们所认为的人！”
I think the generally accepted naming convention is solely to make the name meaningful (and the code clean and simple). In my opinion, if the identifiers in my code need visual cues for any reason, it's too complex and the names are usually not entirely accurate.
I've worked on code that required a manual just to read... "m" meant class-level, "p" meant parameter, etc. The naming convention was developed to make the code easier to read but it ended up doing just the opposite because developers ran with the implication that "good" naming conventions meant readable code.
Just make sure this Dennis Green (former Arizona Cardinal coach) quote applies to your identifiers: "They are who we thought they were!"
我尝试仅在必要时访问成员变量，例如当属性为只读或我想绕过任何设置逻辑时。
原因之一是，如果您稍后向 setter 添加逻辑，您很可能希望它在任何地方都使用。
I try to only access the member variable when I have to, such as when the property is read-only or I want to bypass any setting logic.
One reason for this is that if you do add logic to the setter later, you will most likely want it to be used everywhere.
对于类级变量，我们的编码标准规定使用 mVariableName 或 m_VariableName。 最主要的是跟随你的公司/老师/等。 编码标准/实践。
就我个人而言，仅通过其 getter/setter 来访问该变量（如果有）。 即使该变量仅在类内部使用，我也会使用自动属性。 这样，我添加了一层抽象，这意味着如果我更改了某些内容，需要重构的代码就会减少。
顺便说一句，你的 void 函数不能返回字符串......:-)
For class-level variables, our coding standards say use mVariableName or m_VariableName. The main thing is to follow your company/teachers/etc. coding standards/practices.
I, personaly, only access the variable through its getter/setter if it has one. Even if the variable is only used internally in the class, I use the automatic properties. This way, I add a layer of abstaction wich means less code to refactor if I changed something.
BTW, your void function can't return a string..... :-)
我只是想补充一点，MSDN 命名指南没有指定这一点，因为它只有公共接口的指南（即属性名称、公共方法、公共方法参数等...）它们不关心私有成员样式，所以就微软而言，你和你的团队想要什么就用什么。
I just wanted to add that the MSDN naming guidelines doesn't specify this because it only has guidelines for the public interface (i.e. property names, public methods, public method arguments, etc...) They don't care about private member style, so as far as Microsoft is concerned, you can use whatever you and your team wants.