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

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.