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).
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 namedCacheLevel
.
Though I admit there is a little ambiguity whether they are just recommending this for Enums or for properties in general.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With