How to avoid using the same identifier for Class Names and Property Names?

Question

Here are a few example of classes and properties sharing the same identifier:

public Coordinates Coordinates { get; set; }
public Country Country { get; set; }
public Article Article { get; set; }
public Color Color { get; set; }
public Address Address { get; set; }
public Category Category { get; set; }

This problem occurs more frequently when using POCO with the Entity Framework as the Entity Framework uses the Property Name for the Relationships.

So what to do? Use non-standard class names?

public ClsCoordinates Coordinates { get; set; }
public ClsCountry Country { get; set; }
public ClsArticle Article { get; set; }
public ClsColor Color { get; set; }
public ClsAddress Address { get; set; }
public ClsCategory Category { get; set; }

Yuk

Or use more descriptive Property Names?

public Coordinates GeographicCoordinates { get; set; }
public Country GeographicCountry { get; set; }
public Article WebArticle { get; set; }
public Color BackgroundColor { get; set; }
public Address HomeAddress { get; set; }
public Category ProductCategory { get; set; }

Less than ideal, but can live with it I suppose.

Or JUST LIVE WITH IT?

What are you best practices?

Answer 1

I try to rather use more descriptive property names.

Changing the class name feels like it is defeating the purpose, as where most developers tend to under emphisise the use of good and descriptive Variable/Property names.

As in your example, for instance an Address acan be

public Address HomeAddress { get; set; } 
public Address PostalAddress { get; set; } 
public Address CompanyAddress { get; set; } 

etc. You can see where im going with this.

Answer 2

I personally am not shy about having the class name and the property name match if the names are truly applicable. For example, on an Address class, having a property called Country which is typed as a class named Country makes sense and there really isn't any name for the property that isn't redundant. I try to avoid collisions using descriptive property names, but sometimes the name for the property and its type are the best names to use and using anything else diminishes clarity rather than improves it.

I would strongly recommend against a Hungarian-like prefix on classes. That is just plain fugly.

Answer 3

This is sometimes known as the "Color Color" problem - and my advice is just to live with it.

The C# language specification has been designed for this not to be an issue. From section 7.5.4.1 of the C# 3 spec:

In a member access of the form E.I, if E is a single identifier, and if the meaning of E as a simple-name (§7.5.2) is a constant, field, property, local variable, or parameter with the same type as the meaning of E as a type-name (§3.8), then both possible meanings of E are permitted. The two possible meanings of E.I are never ambiguous, since I must necessarily be a member of the type E in both cases. In other words, the rule simply permits access to the static members and nested types of E where a compile-time error would otherwise have occurred.

(Followed by an example.)

Obviously when you can provide a more descriptive property name, that's great - but quite often the best name really is the same as the property.

This occurs in the framework itself - for example, HttpWebRequest.CookieContainer is of type CookieContainer, and there are various types with an Evidence property of type Evidence.

Answer 4

I think the name of a property should just decribe what it is. When it is an Apple, just name it an Apple.

Why would anyone, just for property readability, use hungarians at class names. It decreases class name readability.

When accessing the Property, you can use the This keyword for preventing yourself to accidently misreading the the property as a class:

class Food
{
    public Apple Apple
    {
        get;
        set;
    }

    public void DoIt()
    {
        this.Apple = new Apple();
    }
}

class Apple
{
}

See SA1101 of StyleCop "Verifies that calls to local members are prefixed with the 'this.' notation."