Roslyn code analyzers - when should I use "this."?

Question

I've always been explicit with my code when using instance members, prefixing them with this. and with static members, prefixing them with the type name.

Roslyn seems not to like this, and politely suggests that you can omit this. and Type. from your code where appropriate...

...so where I would do this... (no pun intended)

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

...roslyn suggests I do this...

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

...however when it comes to using extension methods, it appears that I cannot omit the use of this. for example...

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

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

Questions:

1. Why does Roslyn not seem to like explicit use of this. and Type. ?
2. Why do I need to explicitly use this. for extension methods?
3. Whilst not strictly part of this question, how do I resolve the discrepancy between Roslyn NOT wanting me to use this. and Type. and StyleCop's analyzers insisting that I use them?

Answer 1

You are correct on this behavior. It has struck me too when using Visual Studio 2015 and I wondered the same as you did. Here are my thoughts on this:

1. Why does Roslyn not seem to like explicit use of this. and Type.?

   It is overhead, and it seems it wants to minimize the code needed. I prefer being explicit in my code though. It is much easier to understand the scope of a variable without having knowing the rest of the code. (Maybe it is also a marketing strategy to let us know about the code analyzers... Or am I thinking too much)

2. Why do I need to explicitly use this. for extension methods?

   I guess this is the rule to supply the first parameter of the extension method, the this. Without providing this it doesn't know the context to call the method on. Actually, the extension method this.Sum(x => x) is actually rewritten as Enumerable.Sum(this, x => x). See the 'need' for this? I guess omitting this is technically possible, but I prefer to be explicit in this case too and I am glad the compiler does too.

Answer 2

this. is a syntax that is provided in C# to resolve ambiguity. For example:

class Square
{
    private int size;

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

So using this. to be explicit is rather an oxymoron, because it is solving a problem caused by a lack of explicitness.

The 'best practice' I would recommend is to write code that is not ambiguous in the first place, thus eliminating the need to use this.. Ambiguity is not only disliked by the compiler but it can be extremely confusing for other programmers trying to read your code.

To achieve disambiguation we need to use different names for things like member variables and parameters. The most common approach (apart from this.) is to use naming prefixes to identify members. Many programmers dislike prefixes but this is usually because they have never seen/used a well designed prefix system - I've described my approach here, and once you get used to it, it is a very powerful way of communicating useful information to yourself and your teammates, and eliminating several common types of bugs caused by ambiguity and mixups.