È poco pratica nominare una proprietà / membro uguale al tipo dichiarante in C #?

Ad esempio, una classe come:

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

e quindi una proprietà come:

Dog Dog { get; set; }

Mi è stato detto che se non riesco a trovare un nome più fantasioso per questo, allora devo usare:

Dog DogObject { get; set; }

Qualche idea su come nominarli meglio?

c# naming properties

— Storm Kiernan
fonte

Questo requisito di cui ti è stato detto sembra essere morto di mente, forse a causa dell'eccessiva applicazione di una buona linea guida (non usare solo il nome del tipo quando c'è un nome migliore).

Questo non verrà nemmeno compilato in C # poiché i nomi dei membri non possono essere gli stessi del tipo allegato.

— Lee,

@Lee: penso che il contesto sia che la proprietà è in un altro tipo. Ad esempio, una Personclasse che contiene una Dogproprietà chiamataDog

— goric

Voglio dire, se è davvero un cane, etichettala come tale.

— Thomas Eding,

L'evidenziazione della sintassi del tuo IDE dovrebbe differenziare il tipo e la proprietà. Quando non stai usando un IDE, puoi sempre guardare il contesto.

— Cyanfish,

Risposte:

Potrebbe essere una cattiva pratica, se non fosse per il fatto che è già abbastanza ovvio ciò di cui stai parlando nel tuo codice, in base al contesto.

Dog = new Dog();

Qual è il costruttore del tipo? Qual è l'oggetto? Non confuso? OK, che ne dici

Dog = Dog.Create()?

Qual è l'oggetto? Qual è il metodo statico di fabbrica sul tipo? Non sei ancora confuso? Non la pensavo così.

L'unica volta che ho visto che questo era un potenziale problema è quando l'albero dello spazio dei nomi diventa abbastanza elaborato e il compilatore non riesce a capire l'ambiguità, nel qual caso finisci con qualcosa di simile

Dog = new Some.Namespace.Dog();

In ogni caso, ciò dovrebbe accadere solo con le proprietà automatiche (e forse le enumerazioni), poiché i nomi delle variabili locali sono sempre camelCased, evitando completamente l'ambiguità.

dog = new Dog();

— Robert Harvey
fonte

+1. E le alternative sono tutte peggiori: "TheDog", "AnyDog", "MyDog", ecc. Quando non c'è nulla da aggiungere, è meglio non aggiungere nulla.

— Kevin Cline,

Suppongo che il secondo potrebbe confondersi se per qualche ragione Dogfosse chiamato un metodo di istanza Create, ma a quel punto ti immergeresti in pratiche di codifica piuttosto terribili.

— KDiTraglia,

Non solo questa è una pratica ragionevole, ma la lingua è stata specificamente progettata per permetterlo. Cerca la specifica C # per "Colore colore" per le regole e una giustificazione, e vedi

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

per alcuni casi d'angolo interessanti che derivano da questa decisione.

In nessun caso è necessario nominare una proprietà "DogObject" per evitare di chiamarla come il suo tipo; che contraddice direttamente le linee guida per la progettazione del framework.

— Eric Lippert
fonte

Se il tipo di proprietà è uno le cui istanze non hanno identità (ad es. Color), Tale utilizzo sembra ragionevole. Non mi piace così tanto, però, con mutevole o IDisposabletipi. "Un controllo Font" si riferisce a quegli aspetti dello stato che sono incapsulati dalla proprietà o all'istanza di Fontidentificata dal getter della proprietà?

— supercat,

Va benissimo chiamarlo Doge questo è in realtà ciò che Microsoft consiglia nelle linee guida per la denominazione del Framework :

CONSIDERA dare a una proprietà lo stesso nome del suo tipo.

Ad esempio, la seguente proprietà ottiene e imposta correttamente un valore enum chiamato Color, quindi la proprietà è denominata Color.

Ed ecco l'esempio che usano nella guida sopra:

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

— Isak Savo
fonte