2

已通读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
  • _姓名
  • 姓名
  • myName 或其他一些随机标识符

哪一个（或另一个）最常被接受？

作为后续，在类的方法中，您是引用内部（私有）标识符还是公共属性访问器？

4

14 回答 14

14

我认为，无论您使用什么命名约定，最重要的是保持一致。我的意思是，如果您选择像 _name 一样命名私有成员，那么总是这样做，而不是一次使用 _name，另一次使用 m_name。我个人使用下划线前缀约定。（其中一个原因是因为我使用 NHibernate，而 NHibernate 有一个 'field.camelcase-underscore' 访问策略。

对于你的另一个问题：这取决于你想做什么。
您的属性是否包含额外的逻辑，并且您是否希望在引用它时执行此逻辑？然后使用该属性。你不想执行逻辑？使用该字段。Eric Lippert 在他的博客上写了一篇关于这个的帖子。

对于您的跟进：这一切都取决于情况。如果您的属性包含一些额外的逻辑，并且您不想在从类中访问时执行该额外的逻辑，那么使用支持字段...

于 2009-01-21T20:54:11.800 回答
5

首先 - 对于简单的获取/设置情况，我建议您使用自动实现的属性。如果这样做，编译器将生成基础变量，并且您只引用属性本身。

除此之外，我建议您选择上述之一或任何类似的东西，然后坚持下去。我工作的公司使用 vName，其中“v”表示这是该属性的值。

于 2009-01-21T20:52:03.397 回答
4

我使用 Style Cop，它在您的代码上强制执行一些样式。我发现这非常有用，我所有的团队成员也都在使用它。

虽然围绕 Style Cop 的使用有很多讨论，但我建议的一件事是，如果您使用 Style Cop，那就是启用所有样式。这样，当您在用户之间共享时，事情就会变得容易得多。

这导致的一件事是您不能用下划线命名您的私有字段。所以我一般在写私有字段的时候使用camelCase，然后对公共属性使用PascalCase：

private string name;
public string Name
{
    get { return this.name; }
    set { this.name = value; }
}

Style Cop 还强制使用this.它使事情更容易阅读。

于 2009-06-07T18:42:46.637 回答
3

我在示例代码中看到的最常见的是一个简单的 _ 前缀。

然而，真正重要的是团队同意标准是什么并坚持下去。

于 2009-01-21T20:52:53.007 回答
2

如果您不能像 Brian Rasmussen 建议的那样使用自动实现的属性，并且您必须拥有一个私有成员，那么我建议使用下划线前缀 _name。

在智能感知中，项目是参数、本地成员还是私有成员并不是很明显，因为它们都具有相同的符号（蓝色立方体）。但是，如果您将光标移动到特定项目，则工具提示会告诉您它是哪一个。

我发现下划线前缀是一种方便的视觉辅助工具，无需移动光标就可以立即看出它是私有成员。

于 2009-01-21T20:55:09.677 回答
1

我曾经非常反对 '_' 前缀，但它确实对智能感知很有用，当您想要快速访问成员字段而无需键入许多字母时。

于 2009-01-21T22:04:46.027 回答
0

一方面我同意你应该使用公司标准，另一方面我会尽量遵守行业标准。

于 2009-01-21T20:56:09.927 回答
0

我会回应以前的答案，因为您应该坚持您的团队使用的方案，或者如果您不在团队中，请与您使用的任何方案保持一致。

就个人而言，我使用下划线前缀，因为我发现它给了我一个很好的视觉提示。

于 2009-01-21T21:04:16.087 回答
0

我认为普遍接受的命名约定只是为了使名称有意义（并且代码简洁明了）。在我看来，如果我的代码中的标识符出于某种原因需要视觉提示，那就太复杂了，而且名称通常并不完全准确。

我处理过需要手册才能阅读的代码......“m”表示类级别，“p”表示参数等。开发命名约定是为了使代码更易于阅读，但它最终只做了恰恰相反，因为开发人员认为“好的”命名约定意味着可读的代码。

只要确保丹尼斯格林（前亚利桑那红衣主教教练）的名言适用于你的身份：“他们就是我们认为的人！”

于 2009-01-21T21:50:39.583 回答
0

我尝试仅在必须时访问成员变量，例如当属性为只读或我想绕过任何设置逻辑时。

这样做的一个原因是，如果您稍后确实向 setter 添加了逻辑，您很可能希望它在任何地方都可以使用。

于 2009-01-21T21:51:05.323 回答
0

对于类级变量，我们的编码标准说使用 mVariableName 或 m_VariableName。最主要的是跟随你的公司/老师/等。编码标准/实践。

我个人只通过它的 getter/setter 访问变量（如果有的话）。即使该变量仅在类内部使用，我也使用自动属性。这样，我添加了一层抽象，这意味着如果我改变了一些东西，需要重构的代码更少。

顺便说一句，你的 void 函数不能返回一个字符串..... :-)

于 2009-01-21T22:59:29.413 回答
0

我只是想补充一点，MSDN 命名指南没有指定这一点，因为它只有公共接口的指南（即属性名称、公共方法、公共方法参数等......）他们不关心私有成员样式，就微软而言，你可以使用你和你的团队想要的任何东西。

于 2009-06-07T18:55:24.163 回答
0

首先，我和许多与我共事过的人已经取消了使用“m_”作为私有成员前缀的做法。接下来，每当我在类中引用私有成员时，我通常使用“this.privateMemberVariableName”中的 this 这个词。使用它足以区分该变量不是局部变量或方法内作为参数传递的变量。

如果公共属性名称包含的逻辑不仅仅是引用私有成员变量，例如实例化连接或将属性值保存在视图状态中，我确实会引用公共属性名称。

于 2009-06-07T20:49:48.783 回答
0

框架设计指南书说你不应该在你的变量前面加上 _ - 你应该只使用小写的变量名，我相信 Code Complete 第 2 版说你不应该在你的变量前面加上 m_。

于 2009-06-07T20:54:15.950 回答