Roslyn 代码分析器 - 我什么时候应该使用“this.”？

Question

在使用实例成员时，我的代码总是很明确，在它们前面加上 this. 和静态成员，在它们前面加上类型名称。

Roslyn 似乎不喜欢这样，并礼貌地建议您可以在适当的代码中省略 this. 和 Type....

...所以我会在哪里做这个。.. （没有双关语）

public void DoSomethingCool()
{
    this.CallAwesomeMethod();
    CoolCucumber.DoSomethingLessAewsome();
}

...roslyn 建议我这样做...

public void DoSomethingCool()
{
    CallAwesomeMethod();
    DoSomethingLessAwesome();
}

...但是在使用扩展方法时，我似乎不能省略 this. 的使用，例如...

public int GetTotal()
{
    // This doesn't work    
    return Sum(o => o.Value);

    // This does
    return this.Sum(o => o.Value);
}

问题：

1. 为什么 Roslyn 似乎不喜欢明确使用 this. 和 Type.？
2. 为什么我需要显式使用this. 扩展方法？
3. 虽然严格来说不是这个问题的一部分，但我如何解决 Roslyn 不希望我使用 this. 和 Type. 与 StyleCop 的分析器坚持让我使用它们之间的差异？

Answer 1

您对这种行为是正确的。使用 Visual Studio 2015 时我也很震惊，我想知道和你一样。以下是我对此的看法：

1. 为什么 Roslyn 似乎不喜欢明确使用 this. 和 Type.？

   这是开销，它似乎想最小化所需的代码。不过，我更喜欢在我的代码中明确表达。在不了解其余代码的情况下更容易理解变量的范围。 （也许让我们了解代码分析器也是一种营销策略……还是我想太多了）

2. 为什么我需要为扩展方法显式使用this.？

   我猜这是提供扩展方法的第一个参数this 的规则。如果不提供this，它不知道调用该方法的上下文。实际上，扩展方法this.Sum(x => x)实际上被改写为Enumerable.Sum(this, x => x)。看到this 的“需求”了吗？我想省略这在技术上是可行的，但在这种情况下我也更喜欢明确表示，我很高兴编译器也这样做。

Answer 2

this. 是 C# 中提供的一种语法，用于解决歧义。例如：

class Square
{
    private int size;

    public Square(int size)
    {
        size = size;      // How do we differentiate member and parameter?
    }
}

所以使用this. 明确 是一个矛盾的说法，因为它正在解决一个由缺乏明确性引起的问题。

我建议的“最佳实践”是首先编写明确的代码，从而无需使用this.。歧义不仅是编译器不喜欢的，而且对于试图阅读您的代码的其他程序员来说可能会非常混乱。

为了消除歧义，我们需要为成员变量和参数等事物使用不同的名称。最常见的方法（除了this.）是使用命名前缀来标识成员。许多程序员不喜欢前缀，但这通常是因为他们从未见过/使用过设计良好的前缀系统——我已经描述了我的方法here，一旦你习惯了它，它就是一种非常强大的方式来传达有用的信息您和您的队友，并消除了由歧义和混淆引起的几种常见类型的错误。