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

Qual é o melhor nome para um método que retorna um booleano?

IsSupportContentType

CanSupportContentType

naming naming-standards

— Mediador
fonte

Como a intenção é que o nome transmita claramente estado ou comportamento e você nunca diria "esta classe é compatível com o tipo de conteúdo X", o melhor nome é CanSupportContentType. Você diria algo como "esta classe pode suportar o tipo de conteúdo X".

— Craig

Não é um falante nativo, mas o SupportContentType não seria a opção mais "gramatical"?

— Roman Reiner

O primeiro teria que IsSupportedContentTypeser gramaticalmente correto. (a menos que "suporte tipo de conteúdo" age como um substantivo, o que parece improvável)

— CodesInChaos

Que tal simplesmente supportsContentType? O seguinte é inteiramente legível: if (abc.supportsContentType("text/html")). "pode suportar" implica que existem outras condições para suportar o tipo de conteúdo.

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger?

— RM

Respostas:

106

Is vs. Can

De acordo com as recomendações da convenção de nomenclatura da Microsoft , "Is" e "Can" estão OK (e também "Has") como 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, IsNullablepodem ser encontrados em tipos CLR e métodos. Em todos esses casos, "Is" é seguido por um adjetivo .

Enquanto isso, "pode" indica mais claramente a capacidade de, por exemplo CanEdit, CanRead, CanSeek. Em cada um desses casos, 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 cafona incluir o tipo de argumento no nome do método, pois um desenvolvedor pode ver o tipo de argumento no intellisense. Assim, você pode nomear seu método Supportse defini-lo assim:

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

... que é mais curto e ainda comunica claramente o objetivo. 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)

— John Wu
fonte

É bom quando se lê bem:if ( someClass.Supports(contentType) )

— candied_orange

... ouhasSupportedContentType

— Bergi

Um método chamado "CanSupports" inicial me perguntou quem gastou tempo para tornar o software capaz de suportar latas (como em latas). Apenas "Suporta" é a melhor opção, sem dúvida!

— T. Sar - Restabelece Monica

Às vezes, os desenvolvedores não sabem quando algo "soa estranho", por exemplo, se o inglês não é seu primeiro idioma.

— John Wu

Às vezes, uma versão mais curta é pior. Por exemplo, na biblioteca C ++ Standard que temos std::vector::empty(). Apenas pelo nome, ele esvazia o vetor? Ou ele retorna se o vetor está vazio? Na verdade, o último, uma vez que a tarefa anterior é realizada por std::vector::clear(). Mas, em geral, você deve ler os documentos para ter certeza. Como exemplo oposto, os Qt QVectorsão mais fáceis de entender a esse respeito, já que seu método de verificação de vazio é QVector::isEmpty().

— Ruslan #

Vale ressaltar que o prefixo " should " também pode ser usado. De acordo com as diretrizes da Apple , não apenas " pode " e " deveria ", os verbos modais em geral podem ser usados para nomear funções que retornam booleanas. Não vejo muitos usos de " will ", mas " should " é bom para ganchos de consulta de conselhos, como visto em reactjs:

shouldComponentUpdate: (newProps: any) => boolean

— atormentar
fonte

Should é IMHO muito pobre nomeação, "bem, ele deve fechar o documento, mas eu não sou realmente muito certo"

— Lovis

@lovis: Eu acho que o comentário de Harry é muito válido. Por exemplo, eu poderia delegar algumas ações relacionadas ao banco de dados por meio de uma camada de plug-in, cada plug-in possui um método "ShouldCloseConnection" que informa à estrutura que alguma limpeza deve ser realizada. Apenas um exemplo, mas "should" é definitivamente um prefixo válido.

— greg

@greg Como isso é menos ambíguo que WillCloseConnection?

— Basic

@Lovis Geralmente usamos, is...mas usamos should...em alguns nomes de argumentos de função, locais onde o booleano indica para o que a função deve mudar as coisas . Se uma função pode, opcionalmente, fechar um documento, chamando o parâmetro de controle que isClosedseria preciso (que não está fechado ainda ) e portanto, usaria shouldClosepara indicar que este é o que a função é suposto fazer. (Exemplo Arbitrária; nós provavelmente não têm uma função como esta, particularmente desde fechar um documento deve ser suficiente peso para ter um convite específico.)

— KRyan

@ Basic Pelo menos no nosso caso, will...é reservado para funções assíncronas que retornam uma promessa; se a função descrita no meu comentário anterior for síncrona, o uso will...seria inconsistente com a nossa nomeação.

— KRyan #