Field prefixes

The debate on whether to prefix private variables with a leading "_" or "m_" has engaged a lot of people lately since the public release of Style Cop which which enforces the "m_"-prefix (at least that's what I've been told, I haven't had a chance to try the application myself yet).

I think that prefixes are always bad, whether it's an "I" for interface, "C" for class or "m_" for member. I do appreciate the historic reasons for them but there is really no valid reason anymore, we have the "this" and "Me" keywords in C# and VB to differentiate between member variables and local variables or parameters. The only valid reason as I see it is to differentiate between a field and the property that expose that field.

public class Foo
{
    protected string _bar;

    public string Bar
    {
        get { return _bar; }
        set { _bar = value; }
    }
}

You might say that you could just use camelCasing for the field and PascalCasing for the property, but suppose that the class was to be inherited by VB.Net, "bar" would now be ambigous because VB is case insensitive thus the prefix has some validity. However since the introduction of automatic properties I see no reason for the prefix anymore. The only reason would have to do with performance (you could access the field direclty from inside the class rather than through the property) and I'd say that in most cases that's neglectible and I'd go with the increased maintainability the automatic properties gives you. Premature optimization is the root of all evil. Also in the example, if the backing field was just declared as private (as it should) there would be no issue.