从来没有。永远。如果你有变量阴影，你的命名约定就会崩溃。我的意思是，成员变量没有区别的命名吗?Facepalm指

这个关键字在c#中有几种用法。

限定由相似名称隐藏的成员 将对象本身作为参数传递给其他方法 使对象从方法中返回自身 声明索引器 声明扩展方法 在构造函数之间传递参数 在内部重新分配值类型(struct)值。 在当前实例上调用扩展方法 转换为另一种类型 到同一类中定义的链构造函数

可以通过在作用域中不使用相同名称的成员变量和局部变量来避免第一种用法，例如通过遵循通用命名约定并使用属性(Pascal大小写)而不是字段(驼峰大小写)来避免与局部变量冲突(也是驼峰大小写)。在c# 3.0中，可以使用自动实现的属性轻松地将字段转换为属性。

我并不想这么说，但这并不重要。

认真对待。

看看那些重要的东西:你的项目，你的代码，你的工作，你的个人生活。它们中的任何一个都不会成功依赖于是否使用“this”关键字来限定对字段的访问。这个关键字不会帮助你按时发货。它不会减少bug，也不会对代码质量或可维护性产生明显的影响。它不会让你加薪，也不会让你在办公室花更少的时间。

It's really just a style issue. If you like "this", then use it. If you don't, then don't. If you need it to get correct semantics then use it. The truth is, every programmer has his own unique programing style. That style reflects that particular programmer's notions of what the "most aesthetically pleasing code" should look like. By definition, any other programmer who reads your code is going to have a different programing style. That means there is always going to be something you did that the other guy doesn't like, or would have done differently. At some point some guy is going to read your code and grumble about something.

I wouldn't fret over it. I would just make sure the code is as aesthetically pleasing as possible according to your own tastes. If you ask 10 programmers how to format code, you are going to get about 15 different opinions. A better thing to focus on is how the code is factored. Are things abstracted right? Did I pick meaningful names for things? Is there a lot of code duplication? Are there ways I can simplify stuff? Getting those things right, I think, will have the greatest positive impact on your project, your code, your job, and your life. Coincidentally, it will probably also cause the other guy to grumble the least. If your code works, is easy to read, and is well factored, the other guy isn't going to be scrutinizing how you initialize fields. He's just going to use your code, marvel at it's greatness, and then move on to something else.

在Jakub Šturc的回答中，他关于在构造器之间传递数据的第5条可能需要一些解释。这是在重载构造函数中，并且是强制使用This的一种情况。在下面的例子中，我们可以使用默认形参从无参数构造函数调用参数化构造函数。

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

我发现有时候这是一个特别有用的功能。

这在c++编译器上

如果c++编译器没有立即找到一个符号，它会默默地查找。有时候，大多数时候，这是好的:

如果在子类中没有重载母类的方法，则使用母类的方法。 将一个类型的值提升为另一个类型

但有时候，你只是不想让编译器猜测。您希望编译器提取正确的符号，而不是其他符号。

对我来说，这些时候是在一个方法中，我想访问一个成员方法或成员变量。我只是不想因为我写了printf而不是print而随机抽取一些符号。这个->printf不会被编译。

关键是，对于C遗留库(§)，多年前编写的遗留代码(§§)，或者在复制/粘贴已经过时但仍然活跃的语言中可能发生的任何事情，有时，告诉编译器不要耍花招是一个好主意。

这就是我使用它的原因。

(§)这对我来说仍然是一个谜，但我现在想知道你在源代码中包含<windows.h>头的事实，是不是所有遗留的C库符号都会污染你的全局命名空间的原因

(§§)意识到“你需要包含一个头文件，但是包含这个头文件会破坏你的代码，因为它使用了一些具有通用名称的愚蠢宏”是程序员生活中的俄罗斯轮盘时刻之一

黑C + +铝

我同意“非用不可”的说法。不必要地用它修饰代码并不是一个好主意，因为当你忘记这样做时，编译器不会警告你。这可能会给那些期待它一直在那里的人带来困惑，也就是说，他们必须考虑它。

那么，你什么时候会使用它呢?我只是看了一些随机的代码，并找到了这些例子(我不判断这些是好事还是坏事):

将“yourself”传递给一个函数。 将“你自己”分配给一个指针或类似的东西。 铸造，即上/下铸造(安全或其他)，铸造constness等。 编译器强制消歧。