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?

I do it regularly. It gets a bit irritating with Intellisense, but it reads wonderfully. — Chris Pfohl, Jun 05 '12 at 18:37
It makes perfect sense to me, if I want `FooFrobber`'s `Foo`, I use the `Foo` property. — Marc, Jun 05 '12 at 18:38
[Here is an article on this subject (the "Color Color" problem)](http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx) — Ed S., Jun 05 '12 at 18:39

score 2 · Accepted Answer · edited May 23 '17 at 11:55

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.

Another example in many UI objects is the property Color, which returns a Color. — Daniel Rose, Jun 05 '12 at 18:49
I suppose this is a side question, but why prefer a property instead of a field in the first case (no access modifier changes?) Is it to help preserve "ABI" for later version changes? By the way, thanks for the hint on different access modifiers! — seeker, Jun 06 '12 at 23:11
Thanks for the update. I suppose that I should have worded my question more clearly. Suppose that I start with a field, and later decide to switch to a property -- it seems like I won't change API (existing code will work with a simple recompile). The questions is whether I would break ABI (existing code will work even without a recompile). I guess the (implicit) answer is yes, but it seems like the runtime should be able to handle the change during dynamic linking. — seeker, Jun 10 '12 at 06:15
A link to confirm the ABI change: http://blogs.msdn.com/b/abhinaba/archive/2006/04/11/572694.aspx — seeker, Nov 02 '12 at 23:42

Tigran · Answer 2 · 2012-06-05T19:42:02.317

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.

score 0 · Answer 3 · answered Jun 05 '12 at 18:38

0

I think it's absolutely okay to leave it as it is. The compiler is able to tell if your code refers to the class or the property and why introduce another term if the class name is expressive enough.

answered Jun 05 '12 at 18:38

Dennis Traub

50,557
7
93
108

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

3 Answers3