Should a property have the same name as its type?

Question

I've sometimes seen code written like this :

public class B1
{
}

public class B2
{
    private B1 b1;

    public B1 B1
    {
        get { return b1; }
        set { b1 = value; }
    }
}

i.e. class B2 has a property named "B1", which is also of type "B1".

My gut instinct tells me this is not a good idea, but are there any technical reasons why you should avoid giving a property the same name as its class ?

(I'm using .net 2.0, in case that matters).

Answer 1

Just today, Eric blogged about the 'Color Color' problem.

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

Personally, I would avoid it if possible.

Answer 2

It can obviously be a bit confusing when the name of a property and it's type are the same, but other than that it's not really a problem.

If the name makes sense, it's usually better to let the name and the type be the same. If you can think of a better name, you should of course use that, but you should not try to make up a name at any cost just to avoid this situation.

Answer 3

This common pattern is one of the reasons why I always use this when referring to an instance member within a class. e.g. always

this.SomeMethod(this.SomeProperty);

and never

SomeMethod(SomeProperty);

In most cases, there isn't any actual ambiguity, but I find it helps clarify things. Plus you now know where the property/method is defined.

Answer 4

There's no specific technical problem with it. It might harm or improve readability. In fact, some Microsoft libraries have these kind of properties (specifically, with enum properties, this usually makes sense).

Answer 5

I can only think of one drawback. If you wanted to do something like this:

public class B1
{
        public static void MyFunc(){ ; }
}

public class B2
{
        private B1 b1;

        public B1 B1
        {
                get { return b1; }
                set { b1 = value; }
        }

        public void Foo(){
                B1.MyFunc();
        }
}

You'd have to instead use:

MyNamespace.B1.MyFunc();

A good example of this is common usage is in Winforms programming, where the System.Windows.Forms.Cursor class overlaps with the System.Windows.Forms.Form.Cursor property, so your form events have to access static members using the full namespace.

Answer 6

Another gotcha is with inner types.

I run into this one all the time:

public class Car {
    public enum Make {
        Chevy,
        Ford
    };

    // No good, need to pull Make out of the class or create
    // a name that isn't exactly what you want
    public Make Make {
        get; set;
    }
}