Dénomination des méthodes bool: Is vs. Can vs.?

Quel est le meilleur nom pour une méthode qui retourne un booléen?

IsSupportContentType

CanSupportContentType

naming naming-standards

— Médiateur
source

Puisque l'intention est que le nom transmette clairement l'état ou le comportement, et que vous ne diriez jamais "cette classe est un type de contenu pris en charge X", le meilleur nom est CanSupportContentType. Vous diriez quelque chose comme "cette classe peut prendre en charge le type de contenu X".

— Craig

Pas un locuteur natif mais SupportContentType n'est- il pas l' option la plus "grammaticale"?

— Roman Reiner

Le premier devrait IsSupportedContentTypeêtre grammaticalement correct. (sauf si "type de contenu de support" agit en tant que nom, ce qui semble peu probable)

— CodesInChaos

Qu'en est-il simplement supportsContentType? Ce qui suit est tout à fait lisible: if (abc.supportsContentType("text/html")). "peut supporter" implique qu'il existe d'autres conditions pour prendre en charge le type de contenu.

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger?

— RM

Réponses:

106

Est vs peut

Selon les recommandations de la convention de dénomination Microsoft , "Est" et "Peut" sont corrects (et donc "Has") en tant que préfixe d'un booléen.

En clair, "Is" serait utilisé pour identifier quelque chose à propos du type lui-même, pas ce qu'il peut faire. Par exemple, IsFixed, IsDerivedFrom, IsNullablepeuvent être trouvés dans les types CLR et méthodes. Dans tous ces cas, "Est" est suivi d'un adjectif .

Pendant ce temps, « peut » plus indique clairement une capacité, par exemple CanEdit, CanRead, CanSeek. Dans chacun de ces cas, can est suivi d'un verbe .

Puisque "Support" est un verbe, je pense que dans votre cas, CanSupportContentTypec'est mieux.

Alternative plus courte

Par ailleurs, les conventions stipulent que le préfixe est facultatif. De plus, il est un peu ridicule d'inclure le type d'argument dans le nom de la méthode, puisqu'un développeur peut voir le type de l'argument dans intellisense. Vous pouvez donc simplement nommer votre méthode Supportset la définir comme suit:

public bool Supports(System.Net.Mime.ContentType contentType)

... qui est plus courte et communique toujours clairement le but. Tu l'appellerais comme ça:

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

Ou comme compromis peut-être que c'est mieux:

public bool CanSupport(System.Net.Mime.ContentType contentType)

— John Wu
source

C'est bien quand on lit bien:if ( someClass.Supports(contentType) )

— candied_orange

… OuhasSupportedContentType

— Bergi

Une méthode appelée "CanSupports" me permet tout d’abord de se demander qui a passé du temps à rendre le logiciel capable de prendre en charge les boîtes de conserve (comme dans les boîtes de conserve). "Supports" est la meilleure option, sans aucun doute!

— T. Sar - Réintégrer Monica

Parfois, les développeurs ne peuvent pas dire quand quelque chose "semble étrange", par exemple si l'anglais n'est pas leur langue maternelle.

— John Wu

Parfois, une version plus courte est pire. Par exemple, dans la bibliothèque standard C ++, nous avons std::vector::empty(). De son nom seulement, est-ce qu'il vide le vecteur? Ou renvoie-t-il si le vecteur est vide? En réalité le dernier, puisque le premier travail est fait par std::vector::clear(). Mais vous devez en général lire la documentation pour en être sûr. En tant qu'exemple opposé, Qt's QVectorest plus facile à comprendre à cet égard, puisque sa méthode de vérification du vide est QVector::isEmpty().

— Ruslan

Il est à noter que le préfixe " devrait " peut également être utilisé. Selon la directive d'Apple , non seulement « peut » et « devraient », les verbes modaux en général peuvent être utilisés pour les fonctions de nom que booléen de retour. Je ne vois pas beaucoup d’utilisation de " volonté " mais " devrait " est bien pour les hameçons de conseil-consultants, comme on le voit dans les réactions:

shouldComponentUpdate: (newProps: any) => boolean

— Harry
source

devrait être à mon humble avis, "eh bien, il devrait fermer le document, mais je ne suis en fait pas vraiment sûr"

— Lovis

@ Lovis: Je pense que le commentaire de Harry est très valide. Par exemple, je pourrais déléguer certaines actions liées à la base de données via une couche de plug-in. Chaque plug-in dispose d'une méthode "ShouldCloseConnection" qui informe le framework que certains nettoyages doivent être effectués. Juste un exemple, mais "devrait" est définitivement un préfixe valide.

— greg

@greg Comment est-ce moins ambigu que WillCloseConnection?

— Basic

@Lovis Nous utilisons généralement is...mais nous utilisons should...dans certaines fonctions des noms d'arguments, des endroits où le booléen indique en quoi la fonction est censée changer les choses . Si une fonction peut éventuellement fermer un document, appeler le paramètre qui le contrôle isClosedserait précis (ce n'est pas encore fermé ) et nous utiliserions donc shouldClosepour indiquer que c'est ce que la fonction est supposée faire. (Exemple arbitraire; nous n'aurions probablement pas une fonction comme celle-ci, d'autant plus que la fermeture d'un document devrait être assez pesante pour pouvoir avoir un appel dédié.)

— KRyan

@Basic Au moins dans notre cas, will...est réservé aux fonctions asynchrones qui renvoient une promesse; Si la fonction décrite dans mon précédent commentaire est synchrone, l'utilisation will...serait incompatible avec notre nom.

— Kryan