你在实例变量前面使用’this’吗？
当从类本身访问类的实例变量或属性时，是否用“ this. ”前缀它们？
不，我觉得它是视觉噪音。 我认为这个变量是错误命名风格的拐点。 在我的类型中，我应该能够管理字段，属性和方法的命名。
绝对没有理由将你的支持字段命名为“myfield”，将构造函数的参数命名为“myField”，将属性命名为“myField”。
public class TestClass { private string myField; public TestClass(string myField) { this.myField = myField; } public string MyField {get { return myField;} set {myField = value}} }
就个人而言，我总是在所有私人支持字段中添加_的前缀。
public class TestClass { private string _myField; public TestClass(string myField) { _myField = myField; } public string MyField {get { return _myField;} set {_myField = value}} }
现在使用C＃中的自动属性
public class TestClass { private string MyField {get; set;} public TestClass(string myField) { MyField = myField; } }
除了以上可能是你唯一的另一次输入。 是因为你想看到你当前类型的intellisense。 如果您需要这样做，那么我认为您的类型太大，可能不遵循单一责任原则 。 让我们说你是。 为什么保持这个。 在您实际拨打电话后。 重构它。
我只用过this. 构造函数或setter中的前缀，主要是在传递的参数与相关成员变量具有相同名称的情况下。
在C＃中，我绝对做到了。 主要原因是：
-
是否这样做是一个风格问题。 尽管发生了所有的战斗，我不相信有一个客观更好的方法。
-
我的源分析工具（ StyleCop ）默认需要
this.在实例访问之前。 我的第一点暗示我不应该太在意我是否总是这样做或者总是不这样做，并且因为默认的StyleCop设置总是要求它，我采取阻力最小/最大一致性的路径并遵循默认设置。
我对大多数风格问题都遵循这一理念。 我非常喜欢不在自动格式化IDE中更改默认格式选项。 它只是让每个人的生活更加艰难，而不是那么重要。
它增加了混乱。 所以不行。
绝对。 ‘this’避免使用任何前缀，例如m_。 更重要的是，它可以快速提高代码的性能，这就是为什么：
我真的接受了微软警察（FxCop，StyleCop）。 他们真的帮助我捕捉到通常我甚至都不会想到的东西。 例如，如果方法不引用任何成员变量，则FxCop的一个建议是将该方法标记为静态，因此不必将该方法分配给该类的每个实例。 来自MSDN ：
不访问实例数据或调用实例方法的方法可以标记为static（在Visual Basic中为Shared）。 将方法标记为静态后，编译器将向这些成员发出非虚拟调用站点。 发出非虚拟调用站点将阻止在运行时检查每个调用，以确保当前对象指针为非null。 这可以为性能敏感的代码带来可测量的性能提升。 在某些情况下，无法访问当前对象实例表示正确性问题。
使用’this’为我的成员变量添加前缀。 为我做两件事。 首先，它满足StyleCop。 其次，更重要的是，它可以帮助我快速确定某个方法是否需要标记为静态。
当然，运行FxCop会告诉我是否需要将方法标记为静态。 但是，使用’this’。 帮助我花更多时间编写新代码，减少修复FxCop违规的时间。
我认为这种做法大多数时候都能提高易读性，所以是的。
任何时候我都有一个方法参数，其名称与实例变量（很少）相同，以避免混淆。
不，但后来我写了很多VB;）
关于我唯一一次检查这个/我是当我不记得该成员的确切名称或我需要将其与同名的函数参数区分开时。
不！ 我当然可以看出它可能是有益的，但我所做的任何事情都不够复杂，需要另外一定程度的澄清。
我们正在使用ReSharper来管理所有这些。 大多数情况下，我们删除’this’除非将它保留在构造函数中，因为我们通常使用具有相同名称的构造函数参数。
我这样做，对我来说它增加了一些代码清晰度，是在当前程序还是在类中？
是的，如果我看到这个。 我确定它是本地的，我不需要再看了。 如果没有这个前缀。 （或者可能是’_’）我必须检查它是在本地还是在祖先中声明，或者它是一个参数还是……
所有这些检查在调试过程中需要花费更多时间……
一般是的，我做。 通信范围是可读性的重要方面。 它将它与局部变量，静态方法等区分开来。它还传达了定义是“附近”的。
哦，我只对公共方法/属性这样做。 那些倾向于大写，所以这个.Thing看起来正确。 内部视图看起来像外部视图（myInstance.Thing）。 私有财产通常是小写的，所以对于那些人来说这是一个不太吸引人的想法。
当然，这并不是绝对必要的，有些人更喜欢它更简洁。 但它为我和其他可能会查看代码的开发人员提供了提示。
我做。 当Visual Studio中的Intellisense没有像现在这样聪明时，我养成了习惯。
我不觉得它分散注意力，我想因为我写了很多Python而且习惯于到处看自己。
仅在需要区分参数时，如在setter或构造函数中。 我认为它在不必要的情况下使用“codejunk”，类似于Edward Tufte的图表 。 噪音，而不是信号。
如果您的实例变量名称与方法参数相同 – 它不再是“仅仅是澄清的理由”。 如果你不做前置，可能会导致缺陷。
我认为这就是Ben S的意思 – 但只是想强调 – 这不再是最佳实践的问题。
我经常这样做 – 增加清晰度。 我不认为它会增加杂乱 – 因为我们的大脑很快就会读取它，但是注意它是一个实例变量
我做了很多，因为它使自动完成弹出。