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).
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.
So for me,
m_b1
is member data,b1
is a property (or a local variable or parameter), andB1
is the name of the class.It's fine. The canonical example here is
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:
I don't want to have to say
Ticker StockTicker
orTicker ThisTicker
etc.The Microsoft Naming Guideline for Members state:
Though I admit there is a little ambiguity whether they are just recommending this for Enums or for properties in general.