为什么StyleCop建议使用“this”作为前缀方法或属性调用？

Question

我一直在尝试遵循StyleCop关于项目的指导原则，看看最终的代码是否更好。 大多数规则都是合理的，或者是关于编码标准的意见问题，但有一条规则令我感到困惑，因为我没有看到其他人推荐它，而且因为我没有看到明显的好处：

SA1101：对{method或property name}的调用必须以'this'开头。 前缀表示该项是该类的成员。

在缺点方面，代码显然更加冗长，遵循该规则有什么好处？ 这里有人遵循这条规则吗？

Answer 1

除非我在您需要的场景中，否则我并不真正遵循此指南：

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

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

Answer 2

它可以使代码一目了然。 当你使用this ，它更容易：

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

Answer 3

我认为这篇文章解释了一下

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

...微软的一位杰出的年轻开发人员（好吧，是我）决定自己编写一个小工具，可以检测团队中使用的C＃风格的变化。 StyleCop诞生了。 在接下来的几年里，我们收集了微软各个团队可以找到的所有C＃风格指南，并挑选出这些风格常见的所有最佳实践。 这些形成了第一组StyleCop规则。 这项工作产生的最早规则之一是使用此前缀来调用类成员，并从字段名称中删除任何下划线前缀。 C＃风格已经正式与旧的C ++部落分开。

Answer 4

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将列出你输入的范围内可用的内容，“这个”。 没有必要公开班级成员，除非你完全不知道你编码的是什么，否则你应该能够轻松找到你需要的项目。

即使你完全无能为力，也要使用“这个”。 提示可用的内容，但不要将其留在代码中。 还有一些像Resharper这样的附加组件有助于提高范围的清晰度并更有效地暴露对象的内容。 最好学习如何使用提供给你的工具，然后养成一个被大量同事讨厌的坏习惯。

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

我从来没有遇到任何问题，也没有看到同事开发人员的问题，他们反复与代码范围争吵或编写因为不使用“this”而总是错误的代码。 明确。 “这就是”毫无根据的恐惧。 防止未来的代码错误，并且通常是在无知被重视的地方使用的论据。

编码人员随着经验增长，“这个”。 就像要求某人将训练轮放在自行车上作为成年人一样，因为这是他们首先必须学习如何骑自行车。 成年人可能会在1000次骑车时从自行车上掉下来，但是没有理由强迫他们使用训练轮。

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

Answer 5

请注意，编译器不关心是否this引用前缀（除非名称与本地变量和字段冲突，或者您想在当前实例上调用扩展方法。）

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

仅仅因为微软在内部使用这种风格并不意味着你必须这样做。 StyleCop似乎是一个公开的MS内部工具。 我全都是为了遵守微软关于公共事物的惯例，例如：

• 类型名称在PascalCase中
• 参数名称在camelCase中
• 接口应以字母I为前缀
• 使用单数名称作为枚举，除了它们是[标志]

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

一致性也很重要。 它在阅读代码时减少了认知负担，特别是如果代码风格符合您的预期。 但即使在处理外国编码风格时，如果它是一致的，那么用它也不会花费很长时间。 使用ReSharper和StyleCop等工具可确保您认为重要的一致性。

使用.NET Reflector表明Microsoft无论如何都坚持使用BCL中的StyleCop编码标准。

Answer 6

使用一些基本的原因this （和我不约而同地总是前缀类值与类的他们是一部分井的名字-甚至是类本身内）。

1）清晰度。 你知道在这个瞬间你在类定义中声明了哪些变量，以及你声明为locals，参数和诸如此类的变量。 在两年内，你将不会知道这一点，你将继续进行重新发现的奇妙之旅，这绝对是毫无意义的，如果你事先明确表示父母的话，则不需要。 处理代码的其他人从一开始就不知道，因此立即受益。

2）智能感知。 如果输入'this'。 您将获得帮助中所有特定于实例的成员和属性。 这使得查找事物变得更加容易，特别是如果你维护别人的代码或代码，你几年后就没有看过。 它还可以帮助您避免因误解哪些变量和方法被声明的位置和方式而导致的错误。 它可以帮助您发现在编译器阻塞代码之前不会出现的错误。

3）当然，你可以通过使用前缀和其他技术来达到同样的效果，但是这就引出了一个问题，即为什么你会发明一种机制来处理问题，当有一种机制来构建这种语言时实际支持的语言。 IDE？ 如果您触摸键入，即使在某种程度上，它也会最终降低您的错误率，因为不要强迫您将手指从原位移开以获得下划线键。

我看到很多年轻的程序员通过不输入一两个字符而节省了大量时间。 大部分时间都花在调试上，而不是编码。 不要太担心你的打字速度。 担心您能够多快了解代码中发生的事情。 如果你总共节省了五分钟的编码并且花了十分钟的时间进行调试，那么无论你看起来多么快，你都会放慢速度。

Answer 7

我确实遵循它，因为我认为能够分辨出对静态和实例成员的访问权限非常方便。

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

Answer 8

此外，可以在函数中复制变量名称，因此使用“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; 
  }
}

Answer 9

我主要是出于智能感知的原因。 输入this.很好this. 并获得属性，方法等的consise列表