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?

  • 2
    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 '13 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 '13 at 18:46
  • 3
    @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
  • 3
    I mean, if she is indeed a dog, label her as such. – Thomas Eding Sep 26 '13 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 '13 at 21:51

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();
  • 7
    +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 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 '14 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... – Tobias Knauss Apr 3 '20 at 9:33

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, privacy policy and cookie policy

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