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规则。这项工作产生的最早规则之一是使用 this 前缀来调用类成员，并从字段名称中删除任何下划线前缀。 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

使用＆＃34;这个。＆＃34;，当过度使用或强制风格要求时，只不过是一种伪装的设计，即有＆lt; 1％的开发人员真的不了解代码或他们正在做什么，并且让99％想要编写易于阅读和维护的代码的人感到痛苦。

一旦您开始输入，Intellisence将列出您键入的范围内的可用内容，＆＃34;此。＆＃34;没有必要公开班级成员，除非你完全不知道你编码的是什么，否则你应该能够轻松找到你需要的项目。

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

任何不具备静态，本地，类或全球内容范围的开发人员都不应该依赖于＆＃34;提示＆＃34;表明范围。＆＃34;这＆＃34。比匈牙利符号更糟糕，因为至少匈牙利符号提供了关于变量引用的类型的想法，并提供了一些好处。我宁愿看到＆＃34; _＆＃34;或＆＃34; m＆＃34;用于表示类字段成员然后查看＆＃34;这个。＆＃34;无处不在。

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

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

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

Answer 5

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

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

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

类型名称在PascalCase
参数名称位于camelCase
接口应以字母I
为枚举使用单数名称，除非它们是[标志]

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

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

使用.NET Reflector表明，微软并不擅长遵守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

我主要是因为 intellisense 的原因。键入this.并获取属性，方法等的构建列表非常好。

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

9 个答案: