Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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). – delnan Sep 26 '13 at 18:15
This won't even compile in C# since member names cannot be the same as the enclosing type. – Lee Sep 26 '13 at 18:46
@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 '13 at 18:54
I mean, if she is indeed a dog, label her as such. – Thomas Eding Sep 26 '13 at 19:01
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 '13 at 21:51
up vote 19 down vote accepted

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();
share|improve this answer
+1. And the alternatives are all worse: "TheDog", "AnyDog", "MyDog", etc. When there is nothing to add, it's best not to add anything. – kevin cline Sep 26 '13 at 19:00
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 '13 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

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.

share|improve this answer
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 '14 at 22:31

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 {...} }
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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