CODEWITHSUNDEEP
c#.netnaming-conventions
Moe Sisko
Moe Sisko

Reputation: 12051

Should a property have the same name as its type?

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).

Upvotes: 83

Views: 42409

Answers (10)

glopes
glopes

Reputation: 4390

There is actually an important case where it is not fine to have a property with the same name as its type: nullables.

The following will surprisingly throw a compiler error:

public enum MyEnum
{
    Option1,
    Option2
}

public class A
{
    public MyEnum? MyEnum { get; set; } = MyEnum.Option1;
}

It can be especially frustrating if earlier in the design you make the property not nullable, and later the need comes to make it nullable: all your assignments which used to work fine everywhere will suddenly stop working.

Upvotes: 2

SolutionYogi
SolutionYogi

Reputation: 32243

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

https://learn.microsoft.com/en-us/archive/blogs/ericlippert/color-color

Personally, I would avoid it if possible.

Upvotes: 11

Dan Diplo
Dan Diplo

Reputation: 25359

The Microsoft Naming Guideline for Members state:

Consider giving a property the same name as its type.

When you have a property that is strongly typed to an enumeration, the name of the property can be the same as the name of the enumeration. For example, if you have an enumeration named CacheLevel, a property that returns one of its values can also be named CacheLevel.

Though I admit there is a little ambiguity whether they are just recommending this for Enums or for properties in general.

Upvotes: 19

Annabelle
Annabelle

Reputation: 10716

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.

Upvotes: 4

ChrisW
ChrisW

Reputation: 56123

I give things the same name as their type, except for case: my methods and properties are "lowerCase"; and I therefore wouldn't have the problem that MiffTheFox has.

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

public class B2
{
    private B1 m_b1;

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

    public void Foo()
    {
        B1.myFunc(); //this is Ok, no need to use namespace
    }
}

So for me, m_b1 is member data, b1 is a property (or a local variable or parameter), and B1 is the name of the class.

Upvotes: 0

Chris
Chris

Reputation: 1001

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;
    }
}

Upvotes: 9

Guffa
Guffa

Reputation: 700770

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.

Upvotes: 1

MiffTheFox
MiffTheFox

Reputation: 21575

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.

Upvotes: 14

jason
jason

Reputation: 241779

It's fine. The canonical example here is

public Background {
    public Color Color { get; set; }
}

There are rare issues (corner cases) that come up here, but not enough to warrant avoiding this device. Frankly, I find this device quite useful. I would not enjoy not being able to do the following:

class Ticker { ... }


public StockQuote {
    public Ticker Ticker { get; set; }
}

I don't want to have to say Ticker StockTicker or Ticker ThisTicker etc.

Upvotes: 75

Mehrdad Afshari
Mehrdad Afshari

Reputation: 422242

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).

Upvotes: 4

Related Questions