Denominazione dei metodi bool: Is vs. Can vs.?

Qual è il nome migliore per un metodo che restituisce un valore booleano?

IsSupportContentType

CanSupportContentType

naming naming-standards

— Mediatore
fonte

Poiché l'intento è che il nome trasmetta chiaramente lo stato o il comportamento e non si direbbe mai "questa classe è il tipo di contenuto di supporto X", il nome migliore è CanSupportContentType. Diresti qualcosa del tipo "questa classe può supportare il tipo di contenuto X".

— Craig,

Non un madrelingua, ma non sarebbe non SupportContentType essere l'opzione più "grammaticale"?

— Roman Reiner,

Il primo dovrebbe IsSupportedContentTypeessere grammaticalmente corretto. (a meno che "tipo di contenuto di supporto" non agisca come un nome, il che sembra improbabile)

— CodesInChaos

Che dire semplicemente supportsContentType? Quanto segue è interamente leggibile: if (abc.supportsContentType("text/html")). "può supportare" implica che ci sono ulteriori condizioni per supportare il tipo di contenuto.

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger?

— RM,

Risposte:

106

Is vs. Can

Secondo le raccomandazioni della convenzione di denominazione di Microsoft , sia "Is" che "Can" sono OK (e così anche "Has") come prefisso per un valore booleano.

In parole povere, "Is" verrebbe utilizzato per identificare qualcosa sul tipo stesso, non su ciò che può fare. Ad esempio, IsFixed, IsDerivedFrom, IsNullablepossono essere trovati nei tipi e metodi CLR. In tutti questi casi, "Is" è seguito da un aggettivo .

Nel frattempo, "può" più chiaramente indica una capacità, per esempio CanEdit, CanRead, CanSeek. In ciascuno di questi casi, can è seguito da un verbo .

Poiché "Support" è un verbo, penso che nel tuo caso CanSupportContentTypesia meglio.

Alternativa più breve

D'altra parte, le convenzioni affermano che il prefisso è facoltativo. Inoltre, è un po 'banale includere il tipo di argomento nel nome del metodo, poiché uno sviluppatore può vedere il tipo di argomento in intellisense. Così si potrebbe semplicemente nominare il metodo Supportse definire in questo modo:

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

... che è più breve e comunica chiaramente lo scopo. Lo chiameresti così:

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

O come compromesso forse questo è il migliore:

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

— John Wu
fonte

È bello quando legge bene:if ( someClass.Supports(contentType) )

— candied_orange

... oppurehasSupportedContentType

— Bergi,

Un metodo chiamato "CanSupports" inizialmente mi fa meravigliare di chi abbia impiegato del tempo a rendere il software in grado di supportare le lattine (come nelle lattine). Solo "Supports" è l'opzione migliore, senza dubbio!

— T. Sar - Ripristina Monica

A volte gli sviluppatori non sanno quando qualcosa "sembra strano", ad esempio se l'inglese non è la loro prima lingua.

— John Wu,

A volte una versione più corta è peggio. Ad esempio nella libreria standard C ++ che abbiamo std::vector::empty(). Solo dal suo nome, svuota il vettore? O restituisce se il vettore è vuoto? In realtà quest'ultimo, dal momento che il primo compito è svolto da std::vector::clear(). Ma in generale devi leggere i documenti per essere sicuro. Come esempio opposto, Qt QVectorè più facile da capire a questo proposito, dal momento che il suo metodo di controllo del vuoto è QVector::isEmpty().

— Ruslan,

Vale la pena ricordare che è possibile utilizzare anche il prefisso " should ". Secondo le linee guida di Apple , non solo " can " e " should ", i verbi modali in generale possono essere usati per nominare funzioni che restituiscono valori booleani. Non riesco a vedere molti usi di " volontà ", ma " dovrebbe " è utile per gli hook informativi, come visto in reazioni:

shouldComponentUpdate: (newProps: any) => boolean

— Harry
fonte

dovrebbe essere un nome piuttosto scadente, "beh, dovrebbe chiudere il documento, ma in realtà non sono del tutto sicuro"

— Lovis,

@lovis: penso che il commento di Harry sia molto valido. Ad esempio, potrei delegare alcune azioni relative al database attraverso un livello plugin, ogni plugin ha un metodo "ShouldCloseConnection" che informa il framework che dovrebbe essere eseguita una pulizia. Solo un esempio, ma "dovrebbe" è sicuramente un prefisso valido.

— Greg

@greg In che modo è meno ambiguo di WillCloseConnection?

— Base

@Lovis Generalmente usiamo is...ma usiamo should...in alcuni nomi di argomenti di funzioni, luoghi in cui il valore booleano indica in che cosa la funzione dovrebbe cambiare le cose . Se una funzione può opzionalmente chiudere un documento, chiamando il parametro di controllo che isClosedsarebbe esatto (non è chiuso ancora ), e così dovremmo usare shouldCloseper indicare che questo è ciò che si suppone la funzione di fare. (Esempio arbitrario; probabilmente non avremmo una funzione come questa, soprattutto perché la chiusura di un documento dovrebbe essere abbastanza pesante da avere una chiamata dedicata.)

— KRyan,

@Basic Almeno nel nostro caso, will...è riservato alle funzioni asincrone che restituiscono una promessa; se la funzione descritta nel mio commento precedente è sincrona, l'utilizzo will...sarebbe incompatibile con la nostra denominazione.

— KRyan,