私有字段的命名约定

Kha*_*uez 25 c# naming-conventions private-members

首先,我知道这个问题之前已被问过几次,最后,这主要是个人偏好的问题,但阅读有关该主题的所有主题,有些事情对我来说并不清楚.

基本上,大多数人都同意的一点是,公共成员应该是PascalCased而私人成员应该是低级的.CamelCased.

通常引发争论的问题是是否用私人成员或其他任何东西作为私人成员的前缀.前缀违反了几个StyleCop规则(显然可以关闭)

不加前缀的基本原理是你应该使用它.改为加前缀.

我遇到的问题是我不明白它是如何产生影响的?我的意思是,并不是说你不能在课堂上的公共成员上使用它.

让我们想象一下Customer类,看起来像这样:

class Customer
{
    private int age;

    public int Age
    {
        get { return this.age; }
        set { this.age = value; }
    }
}
Run Code Online (Sandbox Code Playgroud)

(显然,在这么简单的情况下,我可以使用autoproperty,但这只是一个例子).

如果我在这个类中添加了第二个属性,没有什么能阻止我使用this.Age(公共属性)而不是this.age(私有字段)来引用它.有时候,如果在getter级别应用了一些验证或格式化,它甚至可以被发现.

此外,如果我的类的其他一些属性需要修改客户的Age,那么直接使用属性而不是后备字段是有意义的,因为setter也可以实现一些业务规则验证,对吧?

换句话说,我真的不知道this关键字如何避免私有支持成员和公共属性之间的混淆,因为这可以在两者上使用并且IntelliSense显示两者?

谢谢.

Tom*_*ell 54

我非常喜欢私有字段的前导"_"约定,即使它不遵循MS约定:

  1. 它消除了与camel cased参数名称的冲突 - 无需使用"this"

  2. 它是一个可视指示器,表示正在读取对象的内部持久状态,或者 - 更重要的是 - 被写入.这是一个标志,"除了我碰巧看到的特定方法之外,它有副作用",这在查看不熟悉的代码时非常重要.

  • 确实如此.我更喜欢_比"this"更多的原因 - 它更紧凑,而且它不是可选的 - 如果你忘记变量引用中的_,程序将无法编译.但我认为这主要是个人偏好...... (13认同)
  • 我试图理解下划线的优点,但我可以简单地说:使用'this.':1.它消除了对"_"的需要.2.它是一个视觉指示器,指示对象的内部持久状态......你看到了我的观点.你的论点有两种方式. (12认同)
  • 广告2:这不是语法突出应该做的事吗? (2认同)
  • 实际上,如果您检查`.Net Core`的源代码,则会发现许多使用`_xyz`约定的地方。 (2认同)
  • @MohammedNoureldin和其他一些情况下,他们使用`m_xyz`。 (2认同)

Ode*_*ded 14

你太对了.它没有.

this在命名冲突的情况下(例如,与字段名称相同的参数名称),使用" 是一种确保使用类成员的方法".

对我来说,帕斯卡套管公共成员和骆驼套管私人成员一直是一个很好的惯例.


mar*_*c_s 8

使用this.age可以帮助区分Age属性的后备存储和age对象上方法的参数:

public bool CheckIfOlderThan(int age)
{
   // in here, just using "age" isn't clear - is it the method parameter? 
   // The internal field?? Using this.age make that clear!
   return (this.age >= age); 
}
Run Code Online (Sandbox Code Playgroud)

当然,在这种情况下,你也可以给你的参数一个不那么混乱的名称,以避免任何冲突....

但是在属性的实际定义中 - 在后备存储中读取和存储它的值 - 添加它this.并没有真正添加任何东西.我认识的一些人只是喜欢一直使用this.前缀 - 不仅仅是在需要的时候 - 个人偏好,真的......


dze*_*ras 7

使用下划线前缀私有字段与使用"this"基本相同.但是下划线使用起来更快,更短,更优雅(我认为这来自Java).

对于函数参数和私有字段具有相同的名称对我来说似乎有点棘手.不仅有一次我忘了使用"这"导致令人讨厌的NullPointerException(是的,我有一天做了java ... :)).

据我所知,它并没有违反任何FxCop规则,因为它不是匈牙利语.

  • 它绝对不是来自Java.在C/C++中,以下划线开头的标识符通常是为编译器保留的. (3认同)