Os métodos que retornam booleano devem ser nomeados após uma pergunta ou afirmação? [fechadas]


10

Muitas convenções de nomenclatura recomendam que os métodos que retornam um booleano (também chamados de métodos de predicado ) sejam nomeados após uma pergunta . Minha pergunta é: eles realmente não significam que os métodos devem ser nomeados após uma afirmação ?

A diferença pode ser sutil, mas você acaba com nomes diferentes em alguns casos:

  • pergunta : is_pixel_transparent (...)
  • afirmação : pixel_is_transparent (...)

Às vezes, isso não faz diferença e o fraseado é o mesmo:

  • pergunta : end_of_file (...)
  • afirmação : end_of_file (...)

Além disso, parece que na maioria das vezes, o que as pessoas chamam de "perguntas" são na verdade afirmações .

  • key_exists (...) -> isso não é uma pergunta, é uma afirmação.
    Exemplo de uso: if (key_exists (...)) ...
  • array_contains_element (...) -> isso não é uma pergunta, é uma afirmação.
    Exemplo de uso: if (array_contains_element (...)) ...

Então, para reafirmar a pergunta, todos estão significando afirmação quando dizem pergunta ?


3
todas essas coisas que você chama de asserções se tornam perguntas ao adicionar um ponto de interrogação? Key_Exists?
Pieter B

1
"Jon Skeet é incrível" é uma afirmação. - Jon Skeet é incrível? é uma questão. Veja a diferença. Veja a diferença?
Steven A. Lowe

@ Pieter, não, não está em inglês apropriado. O ponto de interrogação faz de uma frase uma pergunta?
Rick #:

@ Steven, acho que meu primeiro exemplo aborda a primeira metade do seu comentário, e o segundo exemplo, a segunda metade. Estou faltando alguma coisa?
Rick19 /

@ Rick: uma asserção deve ser verdadeira, caso contrário, o programa está em um estado indefinido / de erro. Uma pergunta pode ou não ser verdadeira. Eu penso nisso como falha de controle vs fluxo de controle.
Steven A. Lowe

Respostas:


13

O objetivo das convenções de nomenclatura não é fazer com que seu código seja lido como inglês; portanto, você deve estar analisando um pouco demais. Em muitos idiomas, é costume prefixar um método ou função retornando um resultado booleano ou uma variável booleana isquando isso faz sentido. Existem outras tradições (por exemplo, Lisp, Ruby), nas quais um sufixo ?é usado. (Uma tradição mais antiga do Lisp é o sufixo -pdo predicado ).

  • No seu exemplo de transparência de pixel, is_transparentdeve ser um método de um objeto de pixel. Se você estiver em uma língua que não tem objetos, mas deseja simular um estilo OOP, então o tipo normalmente seria o prefixo: Pixel_is_transparent. Observe que o prefixo isé usado apenas para destacar a natureza booleana desse método; já está implícito pela chamada do método ( pixel.transparentfunciona também, mas isso pode se tornar muito ambíguo com outros nomes de propriedades).
  • Para testar o EOF, um método pode ser nomeado at_eof. Isso interpreta o final do arquivo como um local no fluxo, enquanto stream.is_eoftambém funcionaria: aqui, o EOF é um estado específico.
  • Para testar se existe uma entrada, collection.exists(key)seria melhor.
  • array_contains_elementnão é um bom nome de método, pois contém um tipo e o desnecessário element. Melhor: array.contains(elem).

Todos os nomes que sugiro são asserções, ou mais precisamente: predicados. O uso de perguntas não faz nenhum sentido lingüístico quando esses predicados são usados ​​em um contexto if-then-else . A palavra “ asserção ” provavelmente não é ótima aqui, pois é usada para descrever o teste de invariantes em muitos idiomas. A palavra " predicado " seria melhor: uma afirmação verdadeira ou falsa. Uma afirmação é formulada como se fosse verdadeira, não como uma pergunta. A declaração 1 ∈ {}- “ 1é elemento do conjunto vazio” ou “o conjunto vazio contém 1” é uma declaração falsa. A pergunta "o conjunto vazio contém o número 1?" pode ser respondido com sim ou não, mas não é verdadeiro ou falso.


1
+1 na nota sobre como o termo "asserção" não é o termo correto a ser usado aqui devido a uma possível confusão.
Pieter B
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.