¿Es una mala práctica nombrar una propiedad / miembro igual que el tipo de declaración en C #?

Por ejemplo, una clase como:

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

y luego una propiedad como:

Dog Dog { get; set; }

Me han dicho que si no puedo encontrar un nombre más imaginativo para él, entonces debo usar:

Dog DogObject { get; set; }

¿Alguna idea sobre cómo nombrarlos mejor?

c# naming properties

— Tormenta kiernan
fuente

Este requisito sobre el que le han informado parece tener muerte cerebral, tal vez debido a la aplicación excesiva de una buena directriz (no solo use el nombre del tipo cuando haya un nombre mejor).

Esto ni siquiera se compilará en C # ya que los nombres de los miembros no pueden ser los mismos que los del tipo adjunto.

— Lee

@Lee: Creo que el contexto es que la propiedad es de otro tipo. Por ejemplo, una Personclase que contiene una Dogpropiedad llamadaDog

— goric

Quiero decir, si ella es realmente un perro, etiquétala como tal.

— Thomas Eding

El resaltado de sintaxis de su IDE debe diferenciar el tipo y la propiedad. Cuando no está utilizando un IDE, siempre puede mirar el contexto.

— Cyanfish

Respuestas:

Podría ser una mala práctica, si no fuera por el hecho de que ya es bastante obvio de qué estás hablando en tu código, según el contexto.

Dog = new Dog();

¿Cuál es el constructor de tipos? Cual es el objeto? No confundido? OK, que tal

Dog = Dog.Create()?

Cual es el objeto? ¿Cuál es el método de fábrica estático en el tipo? ¿Todavía no estás confundido? No lo creo.

La única vez que he visto que esto es un problema potencial es cuando el árbol del espacio de nombres se vuelve bastante elaborado, y el compilador no puede descubrir la ambigüedad, en cuyo caso terminas con algo como

Dog = new Some.Namespace.Dog();

En cualquier caso, esto solo debería suceder con las Propiedades automáticas (y tal vez enumeraciones), ya que los nombres de las variables locales siempre son camelCased, evitando por completo la ambigüedad.

dog = new Dog();

— Robert Harvey
fuente

+1. Y las alternativas son todas peores: "TheDog", "AnyDog", "MyDog", etc. Cuando no hay nada que agregar, es mejor no agregar nada.

— Kevin Cline

Supongo que el segundo podría ser confuso si, por alguna razón , se Dogllamara un método de instancia Create, pero en ese momento se estaría sumergiendo en algunas prácticas de codificación bastante terribles.

— KDiTraglia

No solo es una práctica razonable, el lenguaje fue diseñado específicamente para permitir esto. Busque la especificación de C # para "Color Color" para las reglas y una justificación, y vea

http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx

para algunos casos interesantes que surgen de esta decisión.

Bajo ninguna circunstancia debe nombrar una propiedad "DogObject" para evitar llamarla igual que su tipo; eso contradice directamente las pautas de diseño del marco.

— Eric Lippert
fuente

Si el tipo de propiedad es uno cuyas instancias no tienen identidad (por ejemplo Color), dicho uso parece razonable. Sin embargo, no me gusta tanto con mutable o IDisposabletipos. ¿Los "controles Font" se refieren a aquellos aspectos del estado que están encapsulados por la propiedad, o a la instancia Fontidentificada por el comprador de la propiedad?

— supercat

Está perfectamente bien llamarlo Dogy, de hecho, esto es lo que Microsoft recomienda en las pautas de nomenclatura de Framework :

CONSIDERE dar a una propiedad el mismo nombre que su tipo.

Por ejemplo, la siguiente propiedad obtiene y establece correctamente un valor de enumeración denominado Color, por lo que la propiedad se denomina Color.

Y aquí está el ejemplo que usan en la guía anterior:

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

— Isak Savo
fuente