为什么StyleCop建议给前缀方法或属性调用加上“ this”？

我一直在尝试在项目上遵循StyleCop的准则，以查看最终的代码是否更好。大多数规则是合理的，或者是关于编码标准的观点，但是有一个规则使我感到困惑，因为我没有看到其他人推荐它，也没有看到明显的好处：

SA1101：对{方法或属性名称}的调用必须以'this'开头。前缀，指示该项目是该类的成员。

不利的一面是，代码显然更冗长，所以遵循该规则有什么好处？这里有人遵守这个规则吗？

一眼就能使代码更清晰。使用时this，更容易：

• 区分静态成员和实例成员。（并区分实例方法和委托。）
• 将实例成员与局部变量和参数区分开（不使用命名约定）。

除非在您需要的情况下，否则我不会真正遵循此指南：

• 有一个实际的不确定性-主要是这会影响任何构造函数（this.name = name;）或类似的东西Equals（return this.id == other.id;）
• 您想要传递对当前实例的引用
• 您要在当前实例上调用扩展方法

除此之外，我认为这很混乱。所以我关闭了规则。

我认为本文对此有所解释

http://blogs.msdn.microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

...微软的一位出色的年轻开发人员（好吧，是我）决定自己编写一个小工具，该工具可以检测团队中使用的C＃风格的差异。StyleCop诞生了。在接下来的几年中，我们收集了可以从Microsoft的各个团队中找到的所有C＃样式指南，并挑选了这些样式共有的所有最佳实践。这些形成了第一套StyleCop规则。这项工作中最早出现的规则之一是使用this前缀调出类成员，并从字段名称中删除所有下划线前缀。C＃风格已正式从其旧的C ++部落中脱颖而出。

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code

当过度使用或强制使用样式要求时，“ this。”的使用仅是一种伪装，其掩饰是只有不到1％的开发人员真正不了解代码或他们在做什么，并使其成为现实。对于希望编写易于阅读和维护的代码的99％的人来说，这是很痛苦的。

一旦您开始键入，Intellisence就会在您键入的区域“此”中列出可用的内容。没有必要公开类成员，除非您对所编写的代码一无所知，否则您应该能够轻松找到所需的项目。

即使您一无所知，也请使用“ this”。提示可用的内容，但不要将其留在代码中。还有诸如Resharper之类的许多附加组件，它们有助于使范围更清晰，更有效地公开对象的内容。最好学习如何使用提供给您的工具，然后养成许多同事讨厌的坏习惯。

任何固有地不了解静态，本地，类或全局内容范围的开发人员都不应依靠“提示”来指示范围。“这个。” 比匈牙利符号更糟，因为至少匈牙利符号提供了有关变量所引用类型的想法，并提供了一些好处。我宁愿看到“ _”或“ m”用来表示类字段成员，然后再看到“ this”。到处。

我从来没有遇到过问题，也从未见过与开发人员反复发生问题的情况，该开发人员经常因为不使用“ this”而在代码范围内争论不休，或者编写的代码总是有错误。明确地。这是毫无根据的恐惧。防止将来的代码错误，通常是重视无知的参数。

程序员随着经验的增长而成长。就像要求成年人在成年人的自行车上戴上训练轮一样，因为这是他们首先要学习如何骑自行车的方式。成年人骑自行车的次数可能是骑自行车的人的千分之一，但这并不是强迫他们使用训练轮的原因。

“这个。” 应该从C＃的语言定义中禁止使用它，不幸的是，只有一个原因使用它，那就是解决歧义，也可以通过更好的代码实践轻松地解决歧义。

请注意，编译器不在乎是否以 this（除非与局部变量和字段发生名称冲突，或者您要在当前实例上调用扩展方法。）

这取决于您的风格。我个人this.从代码中删除，因为我认为它会降低信噪比。

仅仅因为Microsoft在内部使用此样式并不意味着您必须这样做。StyleCop似乎是公开发布的MS内部工具。我全力支持Microsoft关于公共事物的约定，例如：

• 类型名称在PascalCase中
• 参数名称在camelCase中
• 接口应以字母I开头
• 为枚举使用单数名称，除非它们是[Flags]

...但是在代码的私有领域中发生的事情是私有的。做您的团队同意的所有事情。

一致性也很重要。它减少了阅读代码时的认知负担，尤其是在代码风格符合您的期望时。但是，即使在处理外来编码风格时，只要保持一致，那么很快就可以习惯它。使用ReSharper和StyleCop之类的工具来确保您认为重要的地方的一致性。

使用.NET Reflector表示，微软无论如何都不会遵守BCL中的StyleCop编码标准。

使用的一些基本原因 this（我巧合地总是在类值的前面加上它们所属的类的名称，即使在类本身中也是如此）。

1）清晰。您马上就知道在类定义中声明了哪些变量，以及在局部变量，参数中声明了哪些变量。在两年之内，您将不会知道，并且您将进行一次奇妙的重新发现之旅，这绝对是毫无意义的，而且如果您事先明确声明父母是不需要的。从事代码工作的其他人一开始就一无所知，因此立即受益。

2）Intellisense。如果输入“ this”。您将在帮助中获得所有特定于实例的成员和属性。它使查找事情变得容易得多，尤其是如果您要维护别人的代码或几年来没有看过的代码。它还可以帮助您避免由于误解了在何处以及如何声明哪些变量和方法而导致的错误。它可以帮助您发现在编译器阻塞您的代码之前不会显示的错误。

3）当然，您可以通过使用前缀和其他技术来达到相同的效果，但这引出了一个问题，即当您的语言支持的语言中内置了一种机制来解决问题时，为什么要发明一种机制来解决问题IDE？如果您触摸输入（即使是部分触摸输入），也不会降低您的错误率，因为它不会强迫您将手指从原始位置移到下划线键。

我看到许多年轻的程序员通过不键入一两个字符而节省了大量时间。您的大部分时间都将花费在调试而不是编码上。不用担心您的打字速度。担心您能以多快的速度了解代码中发生了什么。如果保存共有5分钟时间编码，赢得了花费额外的10分钟调试，你已经放慢自己了，不管你有多快看起来像你要去。

我确实遵循它，因为我认为乍一看就能区分出对静态成员和实例成员的访问确实很方便。

当然，我必须在构造函数中使用它，因为我通常为构造函数参数赋予与为其值分配给其字段相同的名称。因此，我需要“ this”来访问字段。

另外，可以在函数中复制变量名，因此使用“ this”可以使其更清晰。

class foo {
  private string aString;

  public void SetString(string aString){
    //this.aString refers to the class field
    //aString refers to the method parameter        
    this.aString = aString; 
  }
}

我主要是出于智能方面的考虑。键入this.和获取简明的属性，方法等列表非常好。