为了强调或不强调,这就是问题所在

Question

如果二进制版本将被其他框架语言使用,那么在C#中不使用下划线为私有字段添加前缀是否有任何问题？例如,因为C#是区分大小写的,你可以调用字段"foo"和公共属性"Foo",它可以正常工作.

这会对像VB.NET这样的不区分大小写的语言产生什么影响,如果名称只能通过大小写来区分,那么是否会出现任何CLS兼容(或其他)问题？

Answer 1

重要更新(2016年4月12日):

我们注意到,.NET CoreFX团队的内部标准坚持使用下划线符号而不提供任何有关原因的见解.但是,如果我们仔细观察,以排除#3事情变得很明显,有制度_,t_,s_那建议前缀为什么_选择摆在首位.

3. 我们_camelCase用于内部和私有字段,并尽可能使用readonly.前缀实例字段_,静态字段s_和线程静态字段t_.在静态字段上使用时,readonly应该在static(即static readonly不是readonly static)之后.
4. 我们避免,this.除非绝对必要.

因此,如果您就像.NET CoreFX团队正在开发一些性能关键,多线程,系统级代码,那么您强烈建议您:

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

否则请继续阅读......

原始答案:

让我们首先就我们所谈论的内容达成一致.问题是如果可见性修饰符允许,我们如何从非静态方法和类/子类的构造函数中访问实例成员.

下划线符号

• 建议您在私有字段的名称中使用"_"前缀
• 它还说你绝不应该使用"这个",除非绝对必要

这种表示法

• 建议你只使用"这个".访问任何实例成员

为什么这种符号存在？

因为这就是你的方式

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

例

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",但是必须使用扩展方法
• 这个符号可以让你免于犹豫,你总是使用"这个",期间.

Visual Studio支持

• 下划线表示法在Visual Studio中没有内置支持

• Visual Studio自然支持这种表示法:

  1. http://www.screenr.com/zDCH
  2. "这个." 资格认证:首选非静态方法中使用的所有非静态字段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中.

Answer 2

取自Microsoft StyleCop帮助文件:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

原因: C#中的字段名称以下划线开头.

规则说明:

当字段名称以下划线开头时,会违反此规则.

默认情况下,StyleCop不允许使用下划线,m_等标记本地类字段,而使用'this'.字首.使用'this'的好处.它同样适用于所有元素类型,包括方法,属性等,而不仅仅是字段,使得对类成员的所有调用都可以立即识别,无论使用哪个编辑器来查看代码.另一个优点是它在实例成员和静态成员之间创建了一个快速,可识别的区别,它不会被加上前缀.

如果字段或变量名称旨在匹配与Win32或COM关联的项的名称,因此需要以下划线开头,请将字段或变量放在特殊的NativeMethods类中.NativeMethods类是包含以NativeMethods结尾的名称的任何类,用作Win32或COM包装器的占位符.如果项目放在NativeMethods类中,StyleCop将忽略此违规.

不同的规则描述表明,除了上述内容之外,首选实践是使用小写字母启动私有字段,使用大写字母启用公共字段.

编辑:作为后续,StyleCop的项目页面位于:http://code.msdn.microsoft.com/sourceanalysis.通过帮助文件阅读可以深入了解他们为什么建议各种风格规则.

Answer 3

它没有任何效果.

编写符合CLS的库的部分建议是不要有两个公共/受保护实体,这些实体仅根据具体情况而不同,例如,您不应该

public void foo() {...}

和

public void Foo() {...}

您所描述的内容不是问题,因为私有项目对库的用户不可用

Answer 4

由于我们讨论的是私有字段,因此它不会影响您班级的用户.

但我建议在私有字段中使用下划线,因为它可以使代码更容易理解,例如:

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)
  {
    ..
  }
}

在我们的团队中,我们始终对私有字段使用下划线前缀.因此,在阅读某些代码时,我可以非常轻松地识别私有字段,并将它们与本地和参数区分开来.在某种程度上,下划线可以看作是"这个"的简写版本.

Answer 5

从那时起,在一个具有非常具体和非常毫无意义的风格规则的环境中工作后,我继续创造自己的风格.这是我在很多方面来回翻转的一种类型.我最终决定私有字段永远是_field,局部变量永远不会_并且将是小写,控件的变量名称将松散地遵循匈牙利表示法,参数通常是camelCase.

我讨厌this.关键字,我认为它只会增加太多的代码噪音.我喜欢Resharper的删除多余的这个.关键词.

6年更新: 我正在分析Dictionary<TKey,T>并发访问的特定用法的内部结构,并将私有字段误读为本地变量.私有字段肯定不应该与局部变量的命名约定相同.如果有一个下划线,那将是非常明显的.

Answer 6

我喜欢下划线,因为我可以使用小写名称作为方法参数,如下所示:

public class Person
{
    string _firstName;

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

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

Answer 7

2022 年更新

根据 Microsoft 文档：C# 标识符命名约定

命名私有或内部字段时使用驼峰式大小写（“camelCasing”），并以 _ 为前缀。

益处

在支持语句完成的 IDE 中编辑遵循这些命名约定的 C# 代码时，键入 _ 将显示所有对象范围的成员。

Answer 8

由于Martin提到的原因,我仍然非常喜欢在私有字段前使用下划线,还因为私有字段将在IntelliSense中排序.尽管匈牙利语前缀符号一般都是邪恶的.

然而,最近我发现使用下划线前缀作为私人成员是不受欢迎的,即使我不太清楚为什么.也许别人都知道？它只是前缀原则吗？或者有没有涉及名称修改泛型类型的东西,它们在编译的程序集中得到下划线或什么？

Answer 9

私有字段的 _fieldName 表示法很容易被破坏。使用“这个”。符号是不可能被打破的。你会如何打破 _ 符号？观察：

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

就是这样，我只是违反了你的命名约定，但它可以编译。我希望有一个a）非匈牙利语和b）明确的命名约定。我赞成废除匈牙利命名，这在某种程度上是合格的。您拥有其访问级别，而不是变量名称前面的对象类型。

将此与 Ruby 进行对比，在 Ruby 中，变量名称@my_number将名称与作用域联系在一起并且牢不可破。

编辑：这个答案是否定的。我不在乎，它会留下来。

Answer 10

样式警察是否建议,深入.NET Framework会显示成员变量的大量"_"用法.无论风格警察的创造者是什么推荐,都不是大多数MS员工使用的.:)所以我会坚持使用下划线.因为我个人使用下划线减少了很多错误然后这个(例如:使用varName = varName而不是this.varName = varName,它真的卡在我身上)