Les énumérations en C # devraient-elles avoir leur propre fichier?

J’ai une classe qui utilise une énumération, le enum est actuellement dans son propre fichier, ce qui semble inutile.

Quelle est l’opinion générale sur les énumérations placées dans l’espace de nom d’un fichier dans lequel elles sont consommées? Ou le enum devrait vraiment vivre dans son propre fichier cs?

modifier

Je devrais mentionner que pendant que la classe en question utilise ces énumérations, il en va de même pour les appelants externes. En d’autres termes, une autre classe peut définir ces énumérations. Donc, ils ne sont pas utilisés en interne pour la classe, sinon cette question serait une évidence.

Je ne dirais pas “gaspillage” (combien coûte un fichier supplémentaire?), Mais il est souvent peu avantageux. Habituellement, il y a une classe qui est le plus étroitement associée à l’énumération, et je les place dans le même fichier.

C’est vraiment une question de préférence.

Je préfère mettre chaque énumération dans son propre fichier (de même pour chaque interface, classe et structure, aussi petit soit-il). Cela les rend plus faciles à trouver quand je viens d’une autre solution ou si je n’ai pas déjà de référence au type en question.

En plaçant un seul type dans chaque fichier, il est également plus facile d’identifier les modifications apscopes aux systèmes de contrôle des sources sans les différencier.

C’est entièrement une question de style. Ce que j’ai tendance à faire est d’avoir un fichier appelé Enums.cs dans la solution dans laquelle les déclarations d’énumération sont collectées.

Mais ils sont généralement trouvés par la touche F12 de toute façon.

La question à se poser serait la suivante: y a-t-il quelque chose dans un type d’énumération en C # qui indique que je devrais le traiter différemment de tous les autres types que je crée?

Si l’énumération est publique, elle devrait être traitée comme n’importe quel autre type public. S’il est privé, déclarez-le en tant que membre nested de la classe qui l’utilise. Il n’ya aucune raison impérieuse d’inscrire deux types publics dans le même fichier simplement parce qu’il s’agit d’une énumération. Le fait que ce soit un type public est tout ce qui compte; la saveur de type ne le fait pas.

Un autre avantage de placer chaque type (classe, struct, enum) dans son propre fichier est le contrôle de source. Vous pouvez facilement obtenir l’historique complet du type.

Je place la plupart du temps à l’intérieur de l’espace de noms et en dehors de la classe, de manière à ce que d’autres classes de cet espace soient facilement accessibles, comme ci-dessous.

 namespace UserManagement { public enum UserStatus { Active, InActive } class User { ... } } 

En général, je préfère que mes énumérations soient dans le même fichier que la classe dont il sera très probablement un atsortingbut. Si, par exemple, j’ai une classe Task alors l’énumération TaskStatus sera dans le même fichier.

Cependant, si j’ai des énumérations plus génériques, je les garde contextuellement dans différents fichiers.

Je pense que cela dépend de la scope de la énumération. Par exemple, si l’énumération est spécifique à une classe, par exemple pour éviter le scénario de la constante magique, alors je dirais de le mettre dans le même fichier que la classe:

 enum SearchType { Forward, Reverse } 

Si l’énumération est générale et peut être utilisée par plusieurs classes pour différents scénarios, alors je serais enclin à l’utiliser dans son propre fichier. Par exemple, le ci-dessous pourrait être utilisé à plusieurs fins:

 enum Result { Success, Error } 

Cela dépend de quel access est nécessaire.

Si l’énumération n’est utilisée que par une seule classe, vous pouvez le déclarer dans cette classe, car vous n’avez pas besoin de l’utiliser ailleurs.

Pour les énumérations utilisées par plusieurs classes ou dans une API publique, je conserverai toujours la définition dans son propre fichier dans l’espace de noms approprié. Il est beaucoup plus facile de trouver ce moyen, et la stratégie suit le modèle de one-object-per-file, ce qui est également intéressant à utiliser avec les classes et les interfaces.

J’ai tendance à mettre des énumérations dans leur propre fichier pour une raison très simple: comme pour les classes et les structures, il est bon de savoir exactement où chercher si vous voulez trouver une définition de type: dans le fichier du même nom. (Pour être juste, dans VS, vous pouvez toujours utiliser “Aller à la définition”.)

De toute évidence, cela peut dégénérer. Un collègue où je travaille crée même des fichiers séparés pour les delegates.

L’un des avantages de l’utilisation d’un fichier distinct pour les énumérations est que vous pouvez supprimer la classe d’origine qui a utilisé l’énumération et écrire une nouvelle classe à l’aide de l’énumération.

Si l’énumération est indépendante de la classe d’origine, la placer dans un fichier séparé facilite les modifications futures.

Si vous utilisez le complément de navigateur de fichiers USysWare pour Visual Studio, vous pouvez très rapidement trouver des fichiers de noms particuliers dans votre solution. Imaginez que vous cherchiez une énumération qui ne se trouve pas dans son propre fichier, mais plutôt dans un fichier dans une solution gigantesque.

Pour les petites solutions, peu importe, mais pour les grandes, il est d’autant plus important de conserver les classes et les énumérations dans leurs propres fichiers. Vous pouvez les trouver rapidement, les éditer, etc. Je recommande vivement de mettre votre enum dans son propre fichier.

Et comme cela a été dit … Quel est le gaspillage d’un fichier qui finit par n’être que quelques kb?

J’aime avoir un fichier de énumération publique nommé E contenant chaque énumération distincte, puis on peut accéder à tout enum avec E … et ils sont à un endroit à gérer.

Si vous avez plusieurs projets en une seule solution. Ensuite, mieux créer un autre projet Utilities . Créez ensuite un dossier \Enumerations et créez une static class nestede. Et puis atsortingbuez chaque classe statique où vous créerez un enum qui correspond au nom de vos projets. Par exemple, vous avez un projet nommé DatabaseReader et DatabaseUsers, vous pouvez alors nommer la classe statique comme

 public static class EnumUtility { #region --Database Readers Enum public static class EnumDBReader { public enum Actions { Create, Resortingeve, Update, Delete}; } #endregion #region --Database Users Enum public static class EnumDBUsers { public enum UserIdentity { user, admin }; } #endregion } 

Ensuite, la totalité de la sum pouvant être utilisée dans toutes les solutions par projet sera déclarée. Utilisez # region pour séparer chaque préoccupation. Par cela, il est plus facile de rechercher des énumérations

Très simple avantage énorme de séparer les fichiers. Lorsqu’un object est dans son propre fichier MyObjectName.cs … vous pouvez accéder à l’explorateur de solution et taper MyObjectName.cs et afficher exactement 1 fichier. Tout ce qui améliore le débogage est agréable.

Un autre avantage sur une note similaire, si vous recherchez tous les fichiers ( ctrl + shft + F ) pour un nom, vous pouvez trouver 20 références au nom dans le même fichier … et ce nom trouvé fera partie de différents objects. Dans la fenêtre Rechercher les résultats, vous ne pouvez voir que le numéro de ligne et le nom du fichier. Vous devrez ouvrir le fichier et faire défiler pour savoir quel object la référence trouvée se trouvait.

Tout ce qui facilite le débogage me plaît.