我可以强制使用“这个”吗？ C# .NET 中的关键字？
在引用当前实例成员时，是否有办法在 Visual Studio 中强制使用 this 关键字？
构造函数中存在错误的示例：
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
Foo = Foo; // this should of course be lowercase but it's easy to miss
}
}
此代码可能会在稍后的某个地方生成臭名昭著的“对象引用未设置为对象的实例” 异常。
如何让它工作但仍然很容易错过：
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
Foo = foo; // Valid syntax but unclear.
}
}
这是有效的语法，但很容易错过。
我希望 Visual Studio 强制执行的语法：
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
this.Foo = foo; // this is "safe".
}
}
如果强制执行此约定，我将必须输入 this.Foo = this.Foo 来创建与中相同类型的错误第一个例子。
无论如何，我总是使用 this 关键字，因为它让我在 C# 和其他语言之间切换时的生活更轻松，所以根本不会有任何缺点。
Is there a way to force the use of the this keyword in Visual Studio when referencing current instance members?
Example with a bug in the constructor:
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
Foo = Foo; // this should of course be lowercase but it's easy to miss
}
}
This code will probably generate the infamous 'object reference not set to an instance of an object' exception somewhere later on.
How to make it work but still It's easy to miss:
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
Foo = foo; // Valid syntax but unclear.
}
}
This is valid syntax but it's easy to miss.
The syntax I'd like visual studio enforce:
class MyClass
{
public object Foo { get; set; }
public MyClass(object foo)
{
this.Foo = foo; // this is "safe".
}
}
If this convention is enforced i would have to type this.Foo = this.Foo to create the same type of bug as in the first example.
I always use the this keyword anyway since it makes my life easier while switching between c# and other languages so there wouldn't be any disadvantages at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您只需启用“将警告视为错误”即可解决此问题：
（CS1717，如果您只想为此启用它）
编译器已经告诉您这一点；您应该查看警告（并以零警告为目标）。
关于中间的不清楚：
我不同意 - 这对我来说非常清楚（除非您来自 VB 背景并且已经形成了大小写盲症）。
You can fix this simply by enabling "Treat warnings as errors":
(CS1717 if you want to enable it just for this one)
The compiler already tells you about this; you should be reviewing the warnings (and aim for zero warnings).
Re the middle one being unclear:
I disagree - that is perfectly clear to me (unless you come from a VB background and have developed case-blindness).
不，你不能像这样改变语言的行为。如果您使用 ReSharper，我相信您可以告诉它标记此类事情 - 它可能不会出现在错误列表中，而是出现在整个文件的页边空白和“指示灯”中健康。
我个人不会因为这类事情而失去太多睡眠，因为一旦你测试它就会很明显 - 我只能记得一个场景，它确实是咬伤了我，那是当我在 Windows Phone 7 上运行的类型初始值设定项中遇到堆栈溢出（不完全相同的情况，但又是一个大小写问题）时 - 基本上是困难的调试环境的混合体。
No, you can't change the behaviour of the language like this. If you use ReSharper I believe you can tell it to flag up this sort of thing - it may not come up in the error list, but in the margin and in an "indicator light" for the overall file health.
I personally don't tend to lose too much sleep over this sort of thing, as it's usually obvious as soon as you test - I can only recall one scenario where it's really bitten me, which was when I ended up with a stack overflow (not exactly the same situation, but again a casing issue) within a type initializer, running on Windows Phone 7 - a mixture of difficult debug environments, basically.
如果您不使用此前缀，则可以使用 StyleCop 生成警告。您可以按照这些这些说明
StyleCop 附带了一堆默认规则，其中许多规则很糟糕，但您可以编辑规则文件，使之对您的开发人员最有意义。您还可以共享 StyleCop 文件，以便立即将更改复制给所有开发人员。
这是一个相当不错的解决方案，免费，由 Microsoft 提供，如果您想出一个合适的规则集，那么您的开发人员将创建更多“更整洁”的代码。您还可以按照“方法不应太长”的方式创建自定义规则，在其中定义长度。有很多东西可以玩。
另外我猜你可以将警告设置为错误，但如果你确实确保你的 StyleCop 设置完全符合你的要求。
You can use StyleCop to generate a warning if you do not prefix with this. You can get StyleCop to run as part of the build process by following these these instructions
StyleCop comes with a bunch of default rules, many of them terrible, but you can edit your rules file to make the most sense for your developers. You can also share the StyleCop file so changes are immediately replicated to all your developers.
Its a fairly nice solution, free, provided by Microsoft and if you come up with a suitable rule set then your developers will create much "neater" code. You can also create custom rules along the lines of "Methods shouldn't be too long" where you define the length. Plenty of things to play with.
Also I guess you could set warnings as errors, but if you do make sure your StyleCop settings are exactly as you want them.
您可以使用
StyleCopAnalyzers，规则SA1101：然后您可以右键单击解决方案资源管理器中的规则并将其设置为错误，现在如果不使用“this”，它将无法编译。
You can use
StyleCopAnalyzers, rule SA1101:Then you can right click the rule in solution explorer and set it to error, now it will not compile if "this" is not used.
您可以使用 FXCop\Visual Studio 代码分析创建自定义警告和错误
You can create custom warnings and errors using FXCop\Visual Studio Code Analysis