成员变量的下划线前缀。智能感知

Question

每个人都说“下划线，没有下划线”的辩论纯粹是哲学和用户偏好驱动，但有智能的下划线允许你很容易区分你的成员变量和你的局部变量，从而给你一个具体的好处

对所有成员变量都有下划线的好处是否有任何反驳论据？

Answer 1

是的 - 对某些人而言，它会降低可读性。我相信不同的人以不同的方式阅读（例如，一些内部发声，而另一些则没有）。对于某些人（包括我自己），下划线在我阅读时会中断代码的“流程”。

我认为，如果你在分析本地和实例变量方面遇到困难，那么很可能你的方法太大或你的课程做得太多了。当然并非总是如此，但我不会发现短期课程/方法存在问题。

Answer 2

如果它只是你想要的智能感知，你可以通过输入“this.”来获得它。

好吧，它比“_”还要多4个字符，但智能感知系统会为你调出你的成员。

如果您使用下划线并且您的团队使用下划线，请继续使用它们。其他人会使用“m _”，其他人可能会有其他想法。我使用StyleCop，在我的团队中辩论已结束，我们使用“this”。并且不使用匈牙利风格或下划线前缀。我们再也不用担心了。

[编辑]这不是对你的问题的批评 - 这是一个有效的问题而且值得一提 - 但这场辩论在开发项目上浪费了太多时间。即使我不喜欢每一个关于StyleCop的事情，我都乐意使用它，因为它削减了这种类型的辩论。说真的，我参加了一个小时的会议，这种讨论占据了整个开发团队。疯。就像我说的那样，你的问题是有效的，但请不要浪费你自己的时间为此苦恼，这是不值得的： - ）

Answer 3

使用下划线只是实现这种效果的一种方法。重要的是要保持一致。

Answer 4

下划线可以看作匈牙利符号*的一种形式，但前缀是一个“神奇的角色”，而不是具有意义的东西。

如果您想要更多地了解前缀的用途，可以使用member或mbr或m这样的前缀。有时使用前缀m_，但是下划线用作分隔符而不是前缀的一部分，.NET的命名建议说它不应该用作分隔符。

就个人而言，我已经开始喜欢成员变量的下划线，尽管它是带有隐藏含义的前缀。它不会像任何其他前缀一样混乱名称。

与往常一样，选择一个标准并坚持下去比实际选择标准更为重要。

---

*匈牙利语版本主要用于指定弱类型语言（如VBScript）中的数据类型，但最初的目的是指定变量的其他属性，因此将其用于成员变量更符合原始意图。

Answer 5

只要您在整个项目中使用它，您选择的命名约定无关紧要。

Answer 6

使用此。在我看来，到处都会降低可读性。私有类字段的下划线前缀是完全可以接受的。它几乎不是匈牙利语，这是一个真正糟糕的命名惯例，在intellisense前面打字_加上一个字母是一个非常快速的方式来提出你的清单。 我使用CSLA.NET，很多BO示例使用下划线约定，我继续在我的所有工作中使用它。不要让旧学校的C ++和C开发人员吓唬你认为这不是好习惯 - .NET不会遇到同样的问题。一个很好的例子是在构造函数中传递参数：

public MyObject(int field1, int field2, int field3)
{
    _field1 = field1;
    _field2 = field2;
    _field3 = field3;
}

在我看来比

更具可读性

public MyObject(int field1, int field2, int field3)
{
    this.field1 = field1;
    this.field2 = field2;
    this.field3 = field3;
}

但这是个人品味，正如其他地方所说，一致性是最重要的问题。