Question

This bothers me a lot and I find I write stupid bugs when combined with Intellisense (VS 2008 Pro):

class Foo
{
    public Foo(bool isAction)
    {
        this.IsAction = IsAction;
    }

    public bool IsAction { get; private set; }
}

Did you catch it? I certainly didn’t until IsAction never changed, causing bugs.

Intellisense somehow converted “isA<tab>” to “IsAction” for me which means the property Foo.IsAction is always false regardless of the constructor input. Just brilliant.

I have to say that I particularly hate the “implicit this” (I don’t know if that has a formal name) and I would like to turn it off so it never assumes it. Is there a way to do this? This also applies in calling static methods of the same class.

Alternatively, what naming conventions avoid this little problem? The property must remain “IsAction” so it has to be a convention on the constructor parameter name. Oddly enough, if I name it with the exact matching spelling then this.IsAction = IsAction; works out correctly.

The problem isn’t case-sensitive languages but the implicitness of this. Now that I think about it, this also more of a VS 2008 Pro question than a C#. I can live with code already written without the this but I don’t want to write new code without it which means telling In

---

Noldorin’s answer got me thinking.

Now that I think about it, this also more of a VS 2008 question than a C#. I can live with code already written without the this (though I do change it if I’m in there mucking around) but I don’t want to write new code without it which means telling Intellisense to stop doing it. Can I tell Intellisense to knock it off?

Answer 1

This is a common problem. Microsoft has some recommendations for parameter names but they aren’t terribly helpful in your case.

As other responders have mentioned, you cannot “disable” the C# language scope resolution behavior – your best approach is a naming conventions. Others have mentioned “Hungarian” notation – some people have a knee-jerk reaction to this because of the confusion over the original intent of the notation.

My personal approach, has been to use the character ‘p’ as a prefix to parameter names of public functions. It’s unobtrusive, simple, readily identifiable, and easy to enforce with tools like Resharper.

The particular naming convention you choose is a matter of preference and style; however, there is some benefit from being consistent in the practice you select.

Using my suggested naming convention, you would write your constructor to:

class Foo
{
    public Foo(bool pIsAction)
    {
        this.IsAction = pIsAction;
    }

    public bool IsAction { get; private set; }
}