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

Is vs. Can

In base ai consigli sulla convenzione di denominazione Microsoft , entrambi " Is "e" Can "sono OK (e così è" Has ") come prefisso per un booleano.

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

Nel frattempo, "può" indica più chiaramente una capacità, ad es. CanEdit , CanRead , CanSeek . In ciascuno di questi casi, può essere seguito da un verbo .

Poiché "Support" è un verbo, penso che nel tuo caso CanSupportContentType sia migliore.

Alternativa più breve

D'altra parte, le convenzioni dicono che il prefisso è opzionale. Inoltre, è abbastanza gentile da includere il tipo di argomento nel nome del metodo, poiché uno sviluppatore può vedere il tipo dell'argomento in intellisense. Quindi potresti solo nominare il tuo metodo Supports e definirlo in questo modo:

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

... che è più breve e comunica ancora chiaramente lo scopo. Lo chiameresti in questo modo:

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)

Vale la pena ricordare che è possibile utilizzare anche il prefisso " dovrebbe ". Secondo linee guida di Apple , non solo " può "e" dovrebbe ", i verbi modali in generale possono essere utilizzati per denominare le funzioni che restituiscono booleano. Non riesco a vedere molti usi di " sarà ", ma " dovrebbe " è utile per gli hook di consulenza, come mostrato in reactjs:

shouldComponentUpdate: (newProps: any) => boolean