Nomeação de métodos bool: Is vs. Can vs.?

É vs. Pode

De acordo com as recomendações da convenção de nomenclatura da Microsoft , ambas " É "e" pode "são OK (e assim é" tem ") como um prefixo para um booleano.

Em inglês simples, "Is" seria usado para identificar algo sobre o tipo em si, não o que ele pode fazer. Por exemplo, IsFixed , IsDerivedFrom , IsNullable podem ser encontrados nos tipos e métodos CLR. Em todos esses casos, "Is" é seguido por um adjetivo .

Entretanto, "pode" indicar mais claramente uma capacidade, por ex. CanEdit , CanRead , CanSeek . Em cada um desses casos, o can é seguido por um verbo .

Como "Suporte" é um verbo, acho que no seu caso CanSupportContentType é melhor.

Alternativa mais curta

Por outro lado, as convenções dizem que o prefixo é opcional. Além do mais, é meio brega incluir o tipo de argumento no nome do método, já que um desenvolvedor pode ver o tipo do argumento no intellisense. Então você poderia apenas nomear seu método Supports e defini-lo assim:

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

... que é mais curto e ainda comunica claramente o propósito. Você chamaria assim:

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

Ou como compromisso, talvez seja melhor:

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

Vale a pena mencionar que o prefixo " deve " também pode ser usado. De acordo com a diretriz da Apple , não apenas " pode "e" should ", verbos modais em geral podem ser usados para nomear funções que retornam booleano. Não consigo ver muitos usos de " will ", mas " should " é bom para ganchos que perguntam conselhos, como visto em reactjs:

shouldComponentUpdate: (newProps: any) => boolean