views:

156

answers:

3

I run into this frequently enough that I thought I'd see what others had to say about it.

Using the StyleCop conventions, I find that I often have a property name that is hard to make different than the class name it is accessing. For example:

public class ProjectManager
{
 // Stuff here
}

public class OtherClass
{
     private ProjectManager ProjectManager { get; set; }
}

It compiles and runs, but seems like it would be an easy way to confuse things, even with the use of "this".

+4  A: 

That is a typical naming convention when there will only be a single property of type ProjectManager within any given class. It ceases to be confusing because there are no other uses of the ProjectManager type.

Of course, if there are other uses, then you need different names.

John Saunders
+9  A: 

This is actually a very common pattern in .Net programming. Particularly so with enum types and members as it's the .Net Design Guidelines recommended way of programming.

4.0 design guidelines reference

While it may be a bit confusing, it's not once you've seen it a few times. The tools well support this pattern and given one is a type and the other an instance it's hard to accidentally invert them without causing a compilation error.

JaredPar
Jared, could you post the current version of that link? When .NET 1.1 links are posted, some people wind up following more links, not realizing they are in the .NET 1.1 world.
John Saunders
@John, didn't even realize I'd linked to the 1.1 versions. Thanks for catching that. Updated for the 4.0 guidelines
JaredPar
@Jared: we need to get your company to upgrade to .NET 3.5, or .NET 2.0 at worst. :-)
John Saunders
I guess if it is supported and common practice, it can't be that bad.
Andy Stampor
@Andy: Indeed, it's not that bad. If you can avoid it, great. But the canonical example of "Color Color" is canonical because it illustrates why this is such a common problem. You have a property Color -- what other name could you possibly choose? You have an enum Color -- again, what other name could you possibly choose? Any other name for either seems affected and weird.
Eric Lippert
+1  A: 

I agree with the other answers. For completeness sake, sometimes I find a way to generalize the class name a bit more. I understand your example was just an example, but one way to do it would be:

public class Person
{
  // Stuff here
}

public class OtherClass
{
  private Person ProjectManager { get; set; }
}

This helps make it a bit more readable. But it is perfectly acceptable (and even encouraged) to have identical class name and property.

drharris