37

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?

Improve this question
5
  • 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). Commented 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. Commented 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 Commented Sep 26, 2013 at 18:54
  • 3
    I mean, if she is indeed a dog, label her as such. Commented 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. Commented Sep 26, 2013 at 21:51

3 Answers 3

Reset to default
27

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();
Improve this answer
2
  • 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. Commented 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. Commented Oct 1, 2013 at 15:34
49

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.

Improve this answer
3
  • 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? Commented 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... Commented 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. Commented Mar 24, 2023 at 22:13
12

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.