12

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

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

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

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

...罗斯林建议我这样做...

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.and Type.？
  2. 为什么我需要显式使用this.扩展方法？
  3. 虽然严格来说不是这个问题的一部分，但我如何解决 Roslyn 不希望我使用和 StyleCop 的分析器坚持我使用它们之间的this.差异Type.？
4

2 回答 2

8

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

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

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

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

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

于 2015-11-11T14:10:09.367 回答
1

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

class Square
{
    private int size;

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

所以使用this.to be explicit是一个矛盾的说法，因为它正在解决一个由于缺乏明确性而导致的问题。

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

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

于 2015-11-12T00:19:53.303 回答