For instance, a class like:

class Dog { } //never mind that there's nothing in it...

and then a property like:

Dog Dog { get; set; }

I've been told that if I can't come up with a more imaginative name for it, then I must use:

Dog DogObject { get; set; }

Any thoughts on how to name these better?

  • 3
    This requirement you've been told about seems brain-dead, perhaps due to over-enforcement of a good guideline (don't just use the type name when there's a better name).
    – user7043
    Sep 26, 2013 at 18:15
  • 3
    This won't even compile in C# since member names cannot be the same as the enclosing type.
    – Lee
    Sep 26, 2013 at 18:46
  • 4
    @Lee: I think the context is that the property is in another type. E.g. a Person class containing a Dog property called Dog
    – goric
    Sep 26, 2013 at 18:54
  • 3
    I mean, if she is indeed a dog, label her as such. Sep 26, 2013 at 19:01
  • 1
    Your IDE's syntax highlighting should differentiate the type and property. When you're not using an IDE, you can always look at the context.
    – Cyanfish
    Sep 26, 2013 at 21:51

3 Answers 3


It could be a bad practice, were it not for the fact that it's already pretty obvious what you're talking about in your code, based on context.

Dog = new Dog();

Which is the type constructor? Which is the object? Not confused? OK, how about

Dog = Dog.Create();

Which is the object? Which is the static factory method on the type? Still not confused? I didn't think so.

The only time I've seen this be a potential problem is when the namespace tree gets fairly elaborate, and the compiler can't figure out the ambiguity, in which case you wind up with something like

Dog = new Some.Namespace.Dog();

In any case, this should only happen with Automatic Properties (and perhaps enums), since local variable names are always camelCased, avoiding the ambiguity entirely.

dog = new Dog();
  • 9
    +1. And the alternatives are all worse: "TheDog", "AnyDog", "MyDog", etc. When there is nothing to add, it's best not to add anything. Sep 26, 2013 at 19:00
  • 1
    I suppose that second one could get confusing if for some reason Dog had an instance method called Create, but you'd be diving into some pretty terrible coding practices at that point.
    – KDiTraglia
    Oct 1, 2013 at 15:34

Not only is this a reasonable practice, the language was specifically designed to permit this. Search the C# specification for "Color Color" for the rules and a justification, and see the Microsoft doc on Color Color for some interesting corner cases that arise from this decision.

Under no circumstances should you name a property "DogObject" in order to avoid calling it the same as its type; that directly contradicts the framework design guidelines.

  • If the property type is one whose instances have no identity (e.g. Color), such usage seems reasonable. I don't like it so much, though, with mutable or IDisposable types. Does "a control's Font" refer to those aspects of state which are encapsulated by the property, or to the instance of Font identified by the property getter?
    – supercat
    May 6, 2014 at 22:31
  • Here's the updated link to your blog post: docs.microsoft.com/en-us/archive/blogs/ericlippert/color-color. Since you're from Microsoft, you may ask your colleagues why they broke all the links only for moving to archive... Apr 3, 2020 at 9:33
  • This is not true for nullable enum properties. If you follow the guideline and suddenly have the need to make the property nullable, you will get ambiguous name resolution errors everywhere.
    – glopes
    Mar 24 at 22:13

It's perfectly fine to call it Dog and this is in fact what Microsoft recommends in the Framework naming guidelines:

CONSIDER giving a property the same name as its type.

For example, the following property correctly gets and sets an enum value named Color, so the property is named Color.

And here is the example they use in the above guide:

public enum Color {...}
public class Control {
    public Color Color { get {...} set {...} }

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.