Est-ce une mauvaise pratique de nommer une propriété / un membre identique au type déclarant en C #?

Par exemple, une classe comme:

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

puis une propriété comme:

Dog Dog { get; set; }

On m'a dit que si je ne peux pas trouver un nom plus imaginatif pour cela, alors je dois utiliser:

Dog DogObject { get; set; }

Avez-vous des idées sur la meilleure façon de les nommer?

c# naming properties

— Storm Kiernan
source

Cette exigence dont on vous a parlé semble mortelle, peut-être en raison de l'application excessive d'une bonne directive (n'utilisez pas simplement le nom du type quand il y a un meilleur nom).

Cela ne compilera même pas en C # car les noms de membres ne peuvent pas être les mêmes que le type englobant.

— Lee

@Lee: Je pense que le contexte est que la propriété est d'un autre type. Par exemple, une Personclasse contenant une Dogpropriété appeléeDog

— goric

Je veux dire, si c'est vraiment un chien, étiquetez-la comme telle.

— Thomas Eding

La mise en évidence de la syntaxe de votre IDE doit différencier le type et la propriété. Lorsque vous n'utilisez pas un IDE, vous pouvez toujours regarder le contexte.

— Cyanfish

Réponses:

Cela pourrait être une mauvaise pratique, sans le fait qu'il soit déjà assez évident de quoi vous parlez dans votre code, en fonction du contexte.

Dog = new Dog();

Quel est le constructeur de type? Quel est l'objet? Pas confus? OK, que diriez-vous

Dog = Dog.Create()?

Quel est l'objet? Quelle est la méthode d'usine statique sur le type? Toujours pas confus? Je ne le pensais pas.

La seule fois où j'ai vu un problème potentiel, c'est lorsque l'arbre de l'espace de nommage est assez élaboré et que le compilateur ne peut pas comprendre l'ambiguïté, auquel cas vous vous retrouvez avec quelque chose comme

Dog = new Some.Namespace.Dog();

Dans tous les cas, cela ne devrait se produire qu'avec les propriétés automatiques (et peut-être les énumérations), car les noms de variables locaux sont toujours camelCased, évitant ainsi toute ambiguïté.

dog = new Dog();

— Robert Harvey
source

+1. Et les alternatives sont toutes pires: "TheDog", "AnyDog", "MyDog", etc. Quand il n'y a rien à ajouter, il est préférable de ne rien ajouter.

— Kevin Cline du

Je suppose que le second pourrait être déroutant si, pour une raison quelconque, Dogune méthode d'instance était appelée Create, mais vous plongeriez dans des pratiques de codage assez terribles à ce stade.

— KDiTraglia

Non seulement c'est une pratique raisonnable, mais le langage a été spécialement conçu pour permettre cela. Recherchez les règles et une justification dans la spécification C # pour "Color Color" et consultez

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

pour certains cas d'angle intéressants qui découlent de cette décision.

Vous ne devez en aucun cas nommer une propriété "DogObject" afin d'éviter de l'appeler de la même manière que son type; qui contredit directement les directives de conception du cadre.

— Eric Lippert
source

Si le type de propriété est celui dont les instances n'ont pas d'identité (par exemple Color), une telle utilisation semble raisonnable. Je ne l'aime pas tellement, cependant, avec les IDisposabletypes mutables ou . «Un contrôle Font» fait-il référence aux aspects de l'état qui sont encapsulés par le bien, ou à l'instance Fontidentifiée par le getter du bien?

— supercat

C'est parfaitement bien de l'appeler Doget c'est en fait ce que Microsoft recommande dans les directives de nommage du Framework :

Pensez à donner à une propriété le même nom que son type.

Par exemple, la propriété suivante obtient et définit correctement une valeur d'énumération nommée Color, de sorte que la propriété est nommée Color.

Et voici l'exemple qu'ils utilisent dans le guide ci-dessus:

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

— Isak Savo
source