Is it bad style to have a member with the same name as a class?

Question

Suppose that I have class Foo and

class FooFrobber
{
   private Foo _foo;

   FooFrobber(Foo foo)
   {
       _foo = foo;
   }

   Frob()
   {
      _foo.FrobCount += 1;
   }
}

It seems like _foo is a good name for a private field, but what if I want to make it an internal or protected variable? The convention (http://weblogs.asp.net/lhunt/archive/2004/08/17/CSharpCodingStandardsv113.aspx via Style guide for c#?) seems to be to use a StudlyCaps with no m_ or trailing _, which means that I will declare protected Foo Foo. This seems to work, but it seems a little bit odd to be shadowing a class name. The style guide says that all fields should be private, but that seems a bit excessive (but maybe that's my inner python speaking). At any rate, it seems like you would have the same problem if we wanted to wrap _foo in a property.

Should I always come up with a different name for the field, as in MyFoo? Is it ok to leave this as it is, as the compiler doesn't seem to mind?

Answer 1

It’s allowed and common practice to have fields/properties that share the same name as their type. First example that comes to mind from the FCL is DispatcherObject.Dispatcher, which returns an instance of type Dispatcher.

However, I personally prefer to avoid declaring fields as protected, and use properties instead. If you want to avoid the coding involved with declaring a backing field, you may use an auto-implemented property:

protected Foo Foo { get; set; }

The advantage of using properties is that you can apply different access modifiers for the getter and the setter:

protected Foo Foo { get; private set; }

Edit: The advantage of using protected properties instead of protected fields is that they allow you to change their implementation – for example, to introduce value validation or change notification – without breaking external libraries that might access it.

Suppose, for example, that you want to extend your class to implement INotifyPropertyChanged. If you were using a protected field, there would be no straightforward way of detecting when the value of the field is changed by a consuming assembly (unless you change the implementation of the external assembly as well). If you were using a protected property, you could simply alter its implementation without requiring any changes in consuming assemblies:

private Foo foo;

protected Foo Foo 
{ 
    get
    {
        return foo;
    }
    set
    {
        if (foo != value)
        {
            foo = value;
            OnPropertyChanged("Foo");
        }
    }
}

Edit₂: Several more advantages to using properties over fields are given in LBushkin’s answer.

Changing a field to a property does appear to break the ABI. I haven’t yet found it stated in an authoritative source (I didn’t spend too much time looking); however, per pst’s comment:

The code behind the property can be changed (to use a custom private backing field or whatever). However, changing a Public Member Variable to a Property is a breaking change in the ABI (Application Binary Interface).

Per jstedfast’s answer:

First thing to keep in mind is that property accessors are compiled into methods. This means that it has a different ABI from just reading/writing to a class member variable, even though it may syntactically look the same.

Answer 2

It's a common practice, mainly coming from C++ world, to name fields with _ in front. The naming conversions like that are absolutely ok until they fits the requirements of dev group.

In ideal world, or (say) the direction to follow for in naming of the variables as much as it possible, is do not highlighting in its name the type of the variable, but it's meaning it represents in this program .

So instead of having (say)

string sName, have a string userName, instead of Robot robot, to have Robot conveyor, and so on...

Hope this helps.