在c＃领域和方法之前，关于“ this”关键字的当前最佳实践是什么？

除非需要区分具有相同名称的变量和字段，否则我永远不会放在this.字段或C＃中的任何成员访问前面。我认为这与m_C ++中常用的前缀没有什么不同，并且认为如果您确实需要指定它是成员，则您的类太大。

但是，我办公室中有很多人对此表示强烈反对。

当前认为最佳做法是this.什么？

编辑：为了澄清，我从不使用m_，仅this.在绝对必要时使用。

根据框架设计准则，当提到公共或受保护的字段时：

请勿将前缀用于字段名称。

例如，m_是一个前缀。

因此，this如MSDN 上所述，对字段的公开展示适合使用关键字

要限定被类似名称隐藏的成员，例如：复制

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

引用私有字段时，可以m_根据需要使用。但是，对于公共领域，我建议您遵循最佳做法。

就个人而言，我不喜欢在变量名中使用下划线。我也尝试保持一致。因此，this.name = name;在公共/私有场景中工作都是一个很好的经验法则。

在我们的团队中，我们采用了在较大的类中使用this.or Me.对象限定符的标准，以帮助初级开发人员仅通过查看变量就可以更轻松地区分变量的确切/直接范围。

在代码方面，这是完全不必要的影响，但是它不会阻塞任何内容，因为无论如何它最终都会生成相同的精确MISL代码。我们之所以采用它，只是因为它解决了我们在一些初级人员中发现的直接问题。除此之外，我认为包含它没有帮助。

StyleCop将强制使用this.So，因此，如果您将其视为最佳实践（我这样做），则使用this.Best Practice是最佳实践。

您采用的样式取决于您和您自己的编码标准，“最佳”是您定义的样式。保持一致。不一致地使用它只会导致混乱。

我的推理是，使用this.会引用您正在引用实例属性的事实，因此，举例来说，它有助于突出显示您正在对它们进行突变的事实（如果有的话this.x = ...），这是您可能想知道的。它还强调了一个事实，即您每次看到this.自己的方法都永远不会是静态的。使用类似的约定m_也可以做到这一点，但这是手动操作，如果您将其m_设为静态，或者重构某些方法以从类外部传递值，那么您必须记住要更改名称（如果您正在使用）this然后编译器将迫使您进行更改。

简单地使用this就更容易了，因为如果弄错了，代码将不会编译，如果使用m_它是手动的，并且您没有在使用这些工具。

使用此功能的好处之一m_是，只要键入一点mintellisense即可为您提供所有私有变量的列表，就我个人而言，这样做是有利的。由于类似的原因，我也将s_使用私有静态变量和c_私有常量。这是匈牙利的表示法，但从某种意义上讲，它的意思是因为它在变量名中添加了有用的含义，以便任何其他程序员都可以从其名称中分辨出可能不太明显的内容。

我当然不同意没有任何区分成员变量和非成员变量的方法，因为它们是不同的，并且当我在人们不做任何区分的代码中读取代码时，确实很难阅读。this.只是觉得使用了多余的样板。但是，实际上，这是个人喜好，如果您以一种方式编写一段时间，最终会认为这是对的，而其他所有东西都是错误的。如果该计划是理智的，那么唯一真正重要的是团队中的每个人都是一致的。

this是明确的。这是一个不可错过的视觉标志。

我几乎总是喜欢显式代码而不是隐式代码。这就是为什么我this经常使用。我认为这是最佳做法。

我总是使用“ this”。推理基于两个简单的事实：

• 读取代码比编写代码更困难。
• 您阅读代码的频率高于编写代码的频率。

使用“ this”使任何阅读者都非常清楚（即不仅是作者，而且可能在完全忘记实现细节后的6个月内将作者包括在内），是的，这是我们的类成员在这里谈论。“ m_”等仅是一个约定，并且像任何其他约定一样，它可能会被滥用（或根本不使用）-在编译时或运行时都没有强制执行“ m _” / etc的内容。“ this”更强：您可以将“ m_”放在局部变量上，编译器不会抱怨。您无法使用“ this”来做到这一点。

如果有什么我感到遗憾的是，在语言规范中没有强制使用“ this”。

不错的好处是，在调试时，您可以将鼠标悬停（或添加监视）“ this”，也可以检查所有其他班级成员-有价值的信息。

该this关键字用于特别区分2个变量存在，尤其是在做当你有一个构造函数或方法与具有相同名称的变量，而是可以具有相同的类型。

例：

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

这（例如this.reason = reason）基本上将参数中的值分配给类中的变量。this基本上reason从参数块获取类。

我也一直在想这个问题。在用JavaScript进行了一些广泛的编码之后，我发现自己this.在c＃代码中使用的频率更高（在此之前，我几乎在构造函数或类似方法中排他地使用了它，以避免产生歧义）。这样做无需付出额外的努力即可使代码更加清晰，此外，您不会最终以前缀破坏类成员名称，并且当上下文清晰或在特别复杂的语句中时，仍可以恢复为“快捷方式”使用成员。我只是添加this.，当我有一个更长的方法，更长的参数列表或声明了许多局部变量时，我认为即使强制执行，代码也可以从其他一些清晰度中受益。

但是我个人绝对讨厌m_前缀样式，并不是因为匈牙利语，而是因为下划线是键入的麻烦；）因此，我不认为它是替代方法。我承认它在智能感知方面有其长处，但是您可以再次辩称，如果您不记得成员变量的前几个字母，那么您的课程就很大了。

我为班级成员准备了一个下划线前缀。_someVar;

为什么？乍一看，它是成员，而不是堆栈变量。一目了然的便利。与“ this”关键字相比，它所需的时间更少。

使用this.既不需要也不改变结果的前缀/关键字之类的东西总是主观的。但是，我认为我们可以同意，我们大多数人都希望区分字段和局部变量。一些使用下划线前缀（我觉得这很丑陋，并且是一种匈牙利符号），另一些使用this.关键字。我是后者之一。这一切都与可读性和可理解性有关。如果它更清晰或更易读，我不介意输入一些额外内容。我想在眨眼之间区分字段和变量。

我总是定义名称类似于的字段myField，参数名称和局部变量名称也类似于myField。没有下划线，没有前缀。我this在提到字段的任何地方都使用。这样，我可以在没有任何前缀的情况下将字段与局部变量和参数区分开。当然，在这种情况下，this关键字是必需的：

public Person(string firstName)
{
    this.firstName = firstName;
}

因此，我的属性如下所示（是的，我总是将字段与属性放在一起，而不是放在文件顶部无关的地方）：

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

读起来很不错：返回这个名字。

编辑：我的答案显然不是答案。所以这里是一个编辑。Microsoft编码准则指出：

2.6命名

请勿在成员变量（，m，s_等）中使用前缀。如果要区分局部变量和成员变量，请使用“ this”。在C＃和“我”中。在VB.NET中。

可以在以下位置找到：http : //blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

因此，至少从MS看来似乎没有明确的指导方针，尽管另一个答案确实指出StyleCop将其作为指导方针。在这些事情上没有权限，因此我建议您下定决心，或者在这种情况下让您的团队屈服。没什么大不了的。

我的原始答案 我个人同意您的看法，但也许将两种方法相互对照的阅读理解测试很有价值。否则，这些风格的东西只会让人感到困惑。

我的观点是：我的观点是人们不必要地使他们的代码风格复杂化，并且如果他们需要表明某些东西是类级别的变量，那么代码中可能还会存在其他一些严重的结构性问题，例如古老的食谱方法。将私有变量放在类的顶部，这迫使您不断向上和向下滚动。

这让我印象深刻，因为它们是“这是什么”约定与正确的“它做什么”约定之间的约定。简洁应该优先于简洁。这是动态语言经常重复的一课。我们不需要所有的绒毛！

这个。经常会导致不必要的噪音。

这是我的解决方案：

• 参数名称
• local_variables
• ANY_CONSTANT
• _private_members
• 非私有财产
• _NonPrivateProperty //支持者
• 私人财产
• _privateProperty //支持者