m_或者有时_，好像有某种约定。.Net框架指南允许在私有字段名称上使用_或m_前缀，因为它们对私有字段没有提供任何指导性的规范。如果你在反编译器中查看BCL（基础类库），你会注意到前缀是最普遍的模式。
命名字段的参考页面位于这里。请注意，该指南仅针对公共和受保护的字段使用，私有字段则没有涵盖。
m_portNumber 不仅难看，还会影响可读性。基本上，m 这部分挡住了 portNumber 部分的视线。 - devuxer通常我用下划线为私有成员变量加前缀。
这样做可以让你在阅读代码时更容易发现它们，而且符合微软指南的要求：
public class Something
{
private string _someString = "";
public string SomeString
{
get
{
return _someString;
}
set
{
// Some validation
_someString = value;
}
}
}
正如其他人所说，更重要的是要保持一致性。如果你在一个遵守 m_ 命名规范的团队中，不要试图反叛并采用其他方式。这只会给其他人带来更多的困难。
微软不参与这两个选项中的任何一个。
如果在Visual Studio中使用“重构->封装字段…”来封装字段：
private string _myVar
和
private string myVar
它们都会生成一个类似于这样的属性：
public string MyVar
{
get { return myVar; }
set { myVar = value; }
}
对于微软来说也是一样的 :-) 只需要与开发团队达成协议，让每个人都使用相同的方法。
通常情况下，除非特定情况下，我从不使用私有字段。我使用受保护的属性封装私有字段。这样更适合继承，并且在我看来更加清晰明了。
_”，有些有“m_”，还有一些只是属性的帕斯卡大小写版本。this.someProperty或搜索整个列表的需要。this。。没有规定阻止您使用有效的标识符名称。重要的是要保持一致性。我使用“_”表示所有私有变量，尽管“正确的方式”（例如ReSharper）似乎希望您以小写字母开头声明它们，并通过使用“this.”来区分参数和成员。
_portNumber 这样的命名似乎非常清晰，而 this.portNumber 则增加了长度但没有增加清晰度，并且看起来太像 Java 风格了。除了美学之外，在这些情况下 this. 在语法上是多余的。 - Steven Suditthis. 可以极大地减少 Intellisense 建议的起始池，除了从一个字符（即 this.i）开始工作外，还可以通过 this. 让您扫描本地成员列表以更快地启动您的大脑。因此，虽然阅读代码是冗余的，但在编写代码时肯定是有帮助的。 - drzaus我并不相信有最好的变量和方法书写规范，最重要的是你和你的团队必须保持一致。微软指定的.NET命名约定非常好，但有些人更喜欢其他约定...
就个人而言，我通常会在私有变量和方法前加"_"，然后使用骆驼式大小写，保护级别的变量和方法采用骆驼式大小写，公共变量和方法则采用帕斯卡式大小写，但这只是我个人的偏好。
是的，StyleCop（强制执行MS编码规则）强制执行的命名约定是“无下划线，驼峰式”用于私有实例字段。
值得注意的是，常量/静态只读字段采用“帕斯卡命名法”（必须以大写字母开头但不能全部大写）。
其他命名约定是C++风格的遗留物，这是最初用于编写C#的样式，因为C#团队来自C++。
重要提示：是否使用此编码样式完全取决于开发团队。更重要的是，团队中的每个人都使用相同的样式，而不是使用任何特定的样式。
另一方面，MS在经过深思熟虑后选择了这种样式，因此我将其用作决定性因素。如果没有特别的原因去选择编码样式，我会按照StyleCop的方式进行。