成员变量的下划线前缀。 intellisense
每个人都说“下划线，没有下划线”的辩论纯粹是哲学和用户偏好驱动，但有智能的下划线允许你很容易地将你的成员变量与你的局部变量区分开来，从而给你一个具体的好处
对所有成员变量都有下划线的好处是否有任何反驳论据？
是的 – 对某些人来说，它会降低可读性。 我相信不同的人以不同的方式阅读（例如，一些内部发声，而另一些则没有）。 对于某些人（包括我自己），下划线在我阅读时会中断代码的“流程”。
我认为，如果你在分析本地和实例变量方面遇到困难，那么很可能你的方法太大或你的课程做得太多了。 当然并非总是这样，但我不会发现短期课程/方法存在问题。
如果它只是你想要的intellisense，你可以通过输入“ this. ”来获得它。
好吧，它比“_”多4个字符，但是intellisense会为你调出你的成员。
如果您使用下划线并且您的团队使用下划线，那么继续使用它们。 其他人会使用“ m _”，其他人可能会有其他想法。 我使用StyleCop，在我的团队中辩论已经结束，我们使用“ this 。 并且不使用匈牙利风格或下划线前缀。 我们再也不用担心了。
[编辑]这不是对你的问题的批评 – 这是一个有效的问题，值得问一下 – 但这场辩论在开发项目上浪费了太多时间。 即使我不喜欢每一个关于StyleCop的事情，我都乐意使用它，因为它削减了这种类型的辩论。 说真的，我参加了一个小时的会议，这种讨论占据了整个开发团队。 疯。 就像我说的，你的问题是有效的，但请不要浪费你自己的时间为此苦恼，这是不值得的:-)
使用下划线只是实现这种效果的一种方法。 重要的是要保持一致。
下划线可以看作匈牙利符号*一种forms，但前缀是“魔法角色”而不是具有意义的东西。
如果你想要更多关于前缀的内容，你可以使用像member或mbr或m这样的前缀。 有时使用前缀m_ ，但是下划线用作分隔符而不是前缀的一部分，.NET的命名建议说它不应该用作分隔符。
就个人而言，我已经开始喜欢成员变量的下划线，尽管它是一个带有隐藏含义的前缀。 它不会像任何其他前缀那样混乱名称。
和往常一样，选择标准并坚持下去比实际选择的标准更重要。
*匈牙利语notaition主要用于指定弱类型语言（如VBScript）中的数据类型，但最初的目的是指定变量的其他属性，因此将其用于成员变量更符合原始意图。
只要在整个项目中使用它，您选择的命名约定无关紧要。
用这个。 在我看来，到处都会降低可读性。 私有类字段的下划线前缀是完全可以接受的。 它几乎不是匈牙利语，这是一个真正可怕的命名惯例，在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; }
但这是个人品味，正如其他地方所说，一致性是最重要的问题。