要强调还是不强调，这就是问题所在

如果二进制版本将由其他框架语言使用，则在C＃中不给私有字段加下划线前缀是否存在任何问题？例如，由于C＃区分大小写，因此您可以调用字段“ foo”和公共属性“ Foo”，并且效果很好。

这对不区分大小写的语言（例如VB.NET）有什么影响，如果名称只能用大小写区分，会不会存在CLS兼容（或其他）问题？

它不会有任何作用。

编写符合CLS的库的建议部分是不会有两个公共/保护的实体只有大小写不同，例如，你应该不有

public void foo() {...}

和

public void Foo() {...}

您描述的内容没有问题，因为私有项目对图书馆用户不可用

重要更新（2016年4月12日）：

引起我们注意的是.NET CoreFX团队的内部标准坚持使用下划线符号，而未给出任何原因的见解。但是，如果我们在规则＃3密切关注它变得明显，有制度_，t_，s_那建议前缀为什么_选择摆在首位。

3. 我们_camelCase用于内部和私有字段，并在可能的情况下使用只读。带有的实例字段前缀，带有的_静态字段前缀s_和带的线程静态字段前缀t_。在静态字段上使用时，readonly应紧随其后static（即static readonly不是readonly static）。
4. this.除非绝对必要，否则我们将避免。

因此，如果您就像.NET CoreFX团队一样在处理一些性能关键的多线程系统级代码，那么强烈建议您：

• 遵守他们的编码标准
• 使用下划线符号和
• 不要再看这个答案了

否则请继续阅读...

原始答案：

首先让我们就我们在说什么达成一致。问题是，如果可见性修改器允许，我们如何从非静态方法和类/子类的构造函数中访问实例成员。

下划线符号

• 建议您在专用字段名称中使用“ _”前缀
• 它还说除非绝对必要，否则不要使用“ this”

这个符号

• 建议您始终使用“ this”。访问任何实例成员

为什么存在这个符号？

因为你就是这样

• 当它们共享相同的名称时，从字段中区分出一个参数
• 确保您正在当前实例的上下文中工作

例

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

为什么下划线符号存在？

有些人不喜欢键入“ this”，但是他们仍然需要一种区分字段和参数的方法，因此他们同意在字段前面使用“ _”

例

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

有人可能认为这只是个人品味的问题，两种方法的优劣都同样。但是，在某些方面，该符号要优于下划线符号：

明晰

• 下划线符号使名称混乱
• 此符号使名称完整无缺

认知负荷

• 下划线符号是不一致的，它使您以特殊的方式对待字段，但是每次需要询问自己是否需要属性或字段时，都不能与其他成员一起使用

• 这个表示法是一致的，您不必思考，只需要始终使用“ this”来指代任何成员

更新：如前所述，以下内容不是优势

保养

• 下划线表示法要求您_在重构时保持警惕，例如将字段转换为属性（删除_）或将字段转换为属性（添加_）

• 这个符号没有这个问题

自动补全

当您需要查看实例成员的列表时：

• 下划线符号没有太大帮助，因为当您键入“ _”时，自动完成弹出窗口会向您显示私有字段和链接程序集中的所有可用类型以及其余实例成员
• 通过输入“ this”，此符号可为您提供清晰的答案，您所看到的只是成员列表，仅此而已

歧义性

有时，您必须在没有Intellisense的帮助下处理代码。例如，当您进行代码审查或在线浏览源代码时。

• 下划线符号不明确：当您看到Something.SomethingElse时，您无法分辨Something是一个类，而SomethingElse是其静态属性...还是Something是当前实例属性，该属性具有自己的SomethingElse属性

• 这个表示法很明确：当您看到Something.SomethingElse时，它只能表示具有静态属性的类，并且当您看到此内容时。Something.SomethingElse您知道Something是成员，而SomethingElse是其属性

扩展方式

如果不使用“ this”，则不能在实例本身上使用扩展方法。

• 下划线符号要求您不要使用“ this”，但是对于扩展方法，您必须
• 此表示法使您免于犹豫，您始终使用“ this”（句号）。

Visual Studio支持

• 下划线符号在Visual Studio中没有内置支持

• Visual Studio自然支持此符号：

  1. “这个。” 资格：优先使用非静态方法中使用的所有非静态字段this.作为C＃的开头

官方建议

有很多官方准则明确指出“请勿使用下划线”，尤其是在C＃中

• 下划线符号来自C ++，这是一种有助于避免命名冲突的通用做法，对于VisualBasic.Net，也建议使用它来解决字段“值”和属性“值”实际上具有相同名称的问题，因为VisualBasic不区分大小写

  1. 在Visual Basic中声明的元素名称
  2. VisualBasic.NET中的后备字段

• 对于C＃，建议使用此符号，而明确禁止使用“ _”：

  1. C＃中的此关键字
  2. 字段使用准则：请勿在字段名称或静态字段名称上加上前缀。
  3. 用于地名指南：类型成员的名字：不要使用前缀字段名。
  4. 一般命名约定：X请勿使用下划线，连字符或任何其他非字母数字字符
  5. 质量声明规则CA1707：标识符不应包含下划线
  6. 使用下划线不符合CLS（针对公共和受保护的标识符）
  7. .NET Framework开发人员的内部命名约定：请勿对成员变量使用前缀。如果要区分局部变量和成员变量，则应使用“ this”。在C＃和“我”中。在VB.NET中。

取自Microsoft StyleCop帮助文件：

类型名称： FieldNamesMustNotBeginWithUnderscore

CheckId： SA1309

原因： C＃中的字段名称以下划线开头。

规则说明：

当字段名称以下划线开头时，就会违反此规则。

默认情况下，StyleCop禁止使用下划线，m_等标记本地类字段，而使用“ this”。字首。使用“ this”的优势。它可以同等地应用于所有元素类型，包括方法，属性等，而不仅仅是字段，这使得对类成员的所有调用都可以立即识别，无论使用哪种编辑器查看代码。另一个优点是，它可以在实例成员和静态成员之间建立快速，可识别的区分，而不会添加前缀。

如果字段或变量名称旨在与Win32或COM关联的项的名称匹配，因此需要以下划线开头，请将字段或变量放在特殊的NativeMethods类中。NativeMethods类是任何包含以NativeMethods结尾的名称的类，旨在用作Win32或COM包装程序的占位符。如果将该项放置在NativeMethods类中，则StyleCop将忽略此冲突。

另一种不同的规则说明表明，除上述内容外，首选做法是用小写字母开头私有字段，并用大写字母开头公共字段。

编辑：作为后续，StyleCop的项目页面位于此处：https : //github.com/DotNetAnalyzers/StyleCopAnalyzers。通读帮助文件可以深入了解为什么他们建议各种样式规则。

由于我们在谈论私有字段，因此它不会影响您的班级用户。

但我建议在下划线处使用下划线，因为它可以使代码更易于理解，例如：

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

在我们的团队中，我们始终对私有字段使用下划线前缀。因此，在阅读一些代码时，我可以很容易地识别出私有字段，并把它们与本地变量和参数区分开。从某种意义上说，下划线可以看作“ this”的简写形式。

从那以后，在具有非常具体且毫无意义的样式规则的环境中工作之后，我继续创建自己的样式。这是我经常来回翻转的一种类型。我终于决定私有字段将始终为_field，局部变量将永远不具有_并将为小写，控件的变量名将宽松地采用匈牙利符号，并且参数通常为camelCase。

我讨厌这个this.关键字，它只会增加太多代码噪音。我爱Resharper移除多余的内容。关键词。

6年更新： 我正在分析内部结构Dictionary<TKey,T>的并发访问的特定用法，并将私有字段误读为局部变量。专用字段绝对不应与局部变量使用相同的命名约定。如果有下划线，那将是显而易见的。

我喜欢下划线，因为这样我可以将小写名称用作方法参数，如下所示：

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

我仍然非常喜欢在私有字段前面使用下划线，这是因为马丁提到的原因，也是因为私有字段将在IntelliSense中排序在一起。尽管匈牙利前缀符号通常很邪恶。

但是，最近我发现，对于私有成员使用下划线前缀是不受欢迎的，即使我不太清楚为什么也是如此。也许别人知道吗？仅仅是前缀原则吗？还是在泛型类型的名称处理中涉及到某些问题，这些问题会在编译的程序集中使它们下划线？

是否建议使用样式警察，深入研究.NET Framework会发现很多“ _”用于成员变量。无论Style Cop的创建者推荐什么，这都不是大多数MS员工使用的东西。:)所以我会坚持下划线。因为我个人使用下划线然后使用this犯了很多错误（例如：使用varName = varName而不是this.varName = varName，它确实卡在了我体内）

我认为，从总体上讲，类级别的字段在语言设计中是一个错误。如果C＃的属性具有自己的本地范围，我将更喜欢它：

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

这样就可以完全停止使用字段。

我唯一一次在私有字段下划线加上前缀是在属性需要单独的后备字段时。这也是我唯一一次使用私有字段。（并且由于我从不使用受保护的，内部的或公共的字段，所以这是我唯一使用字段期间的时间。）就我而言，如果变量需要具有类作用域，则它是该类的属性。

专用字段的_fieldName表示法很容易被破坏。使用“ this”。表示法是不可能打破的。您将如何打破_表示法？观察：

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

到了那里，我只是违反了您的命名约定，但是可以编译。我希望有一个命名约定，即a）不匈牙利和b）明确。我赞成取消匈牙利命名，这在某种意义上是合格的。您无需访问变量名称前面的对象类型，而拥有其访问级别。

将此与Ruby进行对比，在Ruby中，变量@my_number的名称将名称绑定到范围中，并且牢不可破。

编辑：这个答案是否定的。我不在乎，它保持不变。

如果要使程序集符合CLS，则可以在assemblyinfo文件中使用CLSCompliant属性。然后，当您的代码包含不符合cls的内容时，编译器将发出抱怨。

然后，当您具有2个仅大小写不同的属性时，编译器将发出错误。另一方面，当您在同一类别中拥有私有领域和公共财产时，就不会有问题。

（但是，我也总是在私有成员的前面加上下划线。这也有助于我在读取代码时明确指出某个变量是成员字段）。

我喜欢在私有字段前面使用下划线，原因有二。已经提到过一个，这些字段在代码和Intellisense中从其关联属性中脱颖而出。第二个原因是，无论我是在VB还是C＃中进行编码，我都可以使用相同的命名约定。

没有任何暗示。编译代码时，对编译器而言重要的是字段/属性的名称空间和可见性。命名标识符时，下划线与任何其他字符一样重要。真正的诀窍是使用您和您周围的人会理解的约定。