Alors, je viens de haine forte> en utilisant Je me trouve à plusieurs reprises de définir mes propres énumes sur chaque nouveau projet dans différents espaces de noms dans différents espaces de noms, comme ceux-ci: P> true code> / false code> comme des arguments de méthode pour "activé" / "désactivé". Pour citer librement Jeff: "Je n'aime pas le savoir sur un niveau fondamental". public enum Clickability
{
Disabled,
Enabled
}
public enum Editability
{
Disabled,
Enabled
}
public enum Serializability
{
Disabled,
Enabled
}
3 Réponses :
Non, il n'y a pas d'énumération de ce type dans la BCL (au meilleur de ma connaissance). Mais il n'est pas difficile de prendre un de ceux que vous créez et de le rendre plus général:
public enum Ability
{
Disabled,
Enabled
}
Le problème avec ceci est qu'il n'en aidait pas réellement dans les véritables cas problématiques qui sont en cas de multiples arguments et qu'il n'est pas clair ce que le «drapeau» contrôle.
Si vous suivez la règle que vous avez Devrait "éviter les doubles négatifs" puis les booléens simples simples sont bien: p> alors Cependant, lorsque vous frappez Une méthode comme: p> alors il ne compte pas que vous utilisiez des booléens ou des énumérums généraux, ils finissent toujours à ressembler à ceci sur le site d'appel: p> foo (true) code>, versets foo (capacité.Enabled ) code> et foo (false) code>, versets foo (capacité.disabled) code> sont vraiment assez évidents pour la plupart. P> Foo(FooOptions.UseBar | FooOptions.UseFlibble, StringComparison.IgnoreCase);
+1. Les énums spécifiques vous donnent également un certain type de sécurité. Vous n'acceptez pas quelque chose accidentellement parce que vous avez manqué le bon ordre des arguments.
Merci. Je pense que je vais coller avec mes énums spécifiques, par exemple, cliquant, éditeur, sérialisalisabilité, car ils offrent une lisibilité supérieure sur le site d'appel.
Qu'est-ce qui ne va pas avec l'utilisation de paramètres ou, mieux encore, quelque chose d'un peu moins verbeux: Je trouverais cela beaucoup plus lisible que des charges de bool avec des noms significatifs? Enum paramètres.
Les définitions de la méthode peuvent être lisibles mais à quoi ressemble les invocations?
@Aakashm: À mon avis, le site d'appel sera également plus lisible que si nous utilisions un "générique" Enum comme l'OP demande: foo (vrai, false, vrai); Versus foo (Genericenum.enabled, genericenum.disabled, genericenum.Enabled);
@Luke (qu'est-ce qui ne va pas avec les paramètres de bool avec des noms significatifs?): Eh bien, spécifique Enums, par exemple, cliquant, éditeur, sérialisabilité, offrir une lisibilité supérieure (comme dans l'auto-documentation) sur le site d'appel pour que quiconque lisait le code sans la nécessité Allez à la définition de la méthode pour voir ce que chaque booléen fait ou méchant.
@Johann: Je conviens que les énums spécifiques pourraient donner une meilleure lisibilité, mais votre question pose de remplacer ces énumes spécifiques avec une seule "générique" enum, qui donnerait une lisibilité plus pauvre que d'utiliser des paramètres booléens bien nommés.
@Luke: Vous êtes correct. Mon exigence réelle cristallisée après avoir posé cette question en premier lieu. Ce n'était pas avant que j'ai réalisé que je voulais vraiment que les énums spécifiques que je définisse toujours.
Y a-t-il une raison particulière que vous n'aimez pas utiliser true / false pour activé / désactivé?
Oui. Enums spécifiques, par exemple, la cliquée, la rédaction, la sérialisalisabilité, offrir une lisibilité supérieure (comme dans l'auto-documentation) sur le site d'appel pour toute personne lisant le code sans qu'il soit nécessaire de passer à la définition de la méthode pour voir ce que chaque booléen fait ou veut dire.
Équilibrer la facilité de codage à la définition des versets La facilité de codage sur le site d'appel est un problème intéressant. Dans la plupart des cas, vous devez optimiser la lisibilité / la sécurité / la clarté sur le site d'appel, car vous avez tendance à avoir plus d'appels à des méthodes que des déclarations d'entre eux :)