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

Question

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

Mat*_*ias 67 .net c# coding-style stylecop

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

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

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

Answer 1

Mar*_*ell 88

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

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

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

这绝对是正确的回应。在你的代码中使用“这个”是愚蠢的，而且从来没有人教过它。 (2认同)

Answer 2

Jef*_*nal 68

它可以使代码一目了然.使用时this,更容易:

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

你可以通过对成员变量使用唯一的词缀(例如,`m_name`对`name`)来完成同样的事情,而对局部变量和参数变量则不使用.不过,这是一个品味问题. (8认同)
如果你使用`this`来区分成员,那么你基本上使用的是命名对流,所以它最好不要用`_`或`m_`作为前缀.事实上,使用"this"需要更多字符会更糟糕. (6认同)
同意类字段与局部变量.类字段的_或m_符号对我来说看起来像是一个古老的,这个规则是一种合理的方法来替换它同时保持可读性. (4认同)
@Loadmaster - 我会添加使用词缀/前缀(如下划线),它通过名称强制使用,而使用'this'关键字,你必须依赖StyleCop等工具来强制使用. (2认同)
Visual Studio建议删除stylecop建议添加的“ this”。他们不能下定决心吗？ (2认同)

Answer 3

Jer*_*eir 38

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

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

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

谢谢你的链接.它告诉我为什么StyleCop规则很大程度上是废话 - 它们是来自分散团队的一堆规则,而不是一套经过深思熟虑的规则,研究确定它们实际上是最好的,对于团队而言各级能力. (19认同)

Answer 4

Chr*_*sCW 16

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

Run Code Online (Sandbox Code Playgroud)

使用"this.",当过度使用或强制样式要求时,只不过是一种伪装的设计,即只有1%的开发人员真的不理解代码或他们正在做什么,并使其成为现实. 99%想要编写易于阅读和维护的代码的人很痛苦.

一旦你开始输入,Intellisence将列出你输入的范围内可用的内容,"这个".没有必要公开班级成员,除非你完全不知道你编码的是什么,否则你应该能够轻松找到你需要的项目.

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

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

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

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

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

8年后，“这个”。由于 TypeScript，它更受欢迎。下划线看起来很糟糕，并且您无法区分实例类、方法或属性。 (2认同)
`任何本质上不了解静态、本地、类或全局内容范围的开发人员都不应该依赖“提示”来指示范围。` – `_` 或 `m` 不是也是一个提示吗？ (2认同)

Answer 5

Dre*_*kes 9

请注意,编译器不关心是否为引用添加前缀this(除非名称与局部变量和字段冲突,或者您想在当前实例上调用扩展方法.)

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

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

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

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

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

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

@Ian - 你说'this`被编译掉了你是对的,但其他的东西,比如带有下划线前缀的字段仍然存在.如果您检查MS现在允许您下载的源代码(以及ReSharper导航到的工具),您将在BCL中看到不同的编码样式. (3认同)
.NET Reflector没有向您显示所编写的源代码,例如它的输出很少告诉您代码的内容,它毕竟是一个反编译器. (2认同)

Answer 6

小智 9

使用的一些基本原因this(我巧合地总是将类值与它们所属的类的名称一起作为前缀 - 即使在类本身中也是如此).

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

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

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

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

您的最后一段实质上与您的第三点矛盾。而且，只要是触摸打字员并且有离开原位转到下划线键的人都是...不是触摸打字员。 (2认同)

归档时间：	16 年前
查看次数：	18463 次
最近记录：	9 年，2 月前