C# myths about best practices?

Question

My colleague keeps telling me of the things listed in comments.

I am confused. Can somebody please demystify these things for me?

class Bar
{
    private int _a;

    public int A
    {
        get { return _a; }
        set { _a = value; }
    }

    private Foo _objfoo;

    public Foo OFoo
    {
        get { return _objfoo; }
        set { _objfoo = value; }
    }

    public Bar(int a, Foo foo)
    {
        // this is a bad idea
        A = a;
        OFoo = foo;
    }

    // MYTHS
    private void Method()
    {
        this.A    //1 -
        this._a   //2 - use this when inside the class e.g. if(this._a == 2)
        A         //3 - use this outside the class e.g. barObj.A
        _a        //4 - 
                  // Not using this.xxx creates threading issues.
    }
}
class Foo
{
    // implementation
}

Answer 1

The this. is redundant if there isn't a name collision. You only need it when you need a reference to the current object or if you have an argument with the same name as a field.

Threading issues have nothing to do with it. The confusion maybe comes from the fact that most static members are implemented so that they are thread-safe and static members cannot (!) be called with this. since they aren't bound to the instance.

Answer 2

"Not using this.xxx creates threading issues"

is a complete myth. Just ask your co-worker to check the generate IL and have him explain why they are the same whether you add this or not.

"use this when inside the class eg if(this._a == 2)"

is down to what you want to achieve. What your co-worker seems to be saying is always reference the private field, which does not seem to me sensible. Often you want to access the public property, even inside a class, since the getter may modify the value (for instance, a property of type List may return a new List instance when the list is null to avoid null reference exceptions when accessing the property).

Answer 3

My personal "best practice" is to always use this. Yes it's redundant but it's great way to identify from the first look where the state of the instance is chaged or retrieved when you consider multi-threaded app.

Answer 4

It may help to ask your co-worker why he considers these suggestions are best practice? Often people quote best-practice "rules" that they have picked up somewhere without any real understanding of the reasons behind the practices.

As Lucero says, the "this" is not required unless () there is a name collision. However, some people like to include the "this" when it is not strictly required, because they believe it enhances readability / more clearly shows the programmers intentions. In my opinion, this is a matter of personal preference rather than anything else.

As for the "bad idea" in your "Bar" method: Your co-worker may consider this bad practice for the following reason: if the setter method for "A" is altered to have some side effect then A=a; will also produce this side effect, whereas _a = a; will just set the private variable. In my view, best practice is a matter of being aware of the difference rather than prefering one over another.

Finally, the "threading issues" are nonsense - AFAIK "this" has nothing to do with threading.

Answer 5

The number 2 is a myth that is easily debunked by mentioning automatic properties. Automatic properties allow you to define a property without the backing field which is automatically generated by the compiler. So ask your co-worker what is his opinion about automatic properties.