¿Deberían nombrarse los métodos que devuelven booleanos después de una pregunta o una afirmación? [cerrado]


10

Muchas convenciones de nomenclatura recomiendan que los métodos que devuelven un valor booleano (también llamados métodos predicados ) se nombren después de una pregunta . Mi pregunta es: ¿no significan realmente que los métodos deben nombrarse después de una afirmación ?

La diferencia puede ser sutil, pero terminas con nombres diferentes en algunos casos:

  • pregunta : is_pixel_transparent (...)
  • aserción : pixel_is_transparent (...)

A veces, esto no hace ninguna diferencia y la redacción es la misma:

  • pregunta : end_of_file (...)
  • aserción : end_of_file (...)

Además, parece que la mayoría de las veces, lo que las personas llaman "preguntas" son en realidad afirmaciones .

  • key_exists (...) -> esto no es una pregunta, es una afirmación.
    Ejemplo de uso: if (key_exists (...)) ...
  • array_contains_element (...) -> esto no es una pregunta, es una afirmación.
    Ejemplo de uso: if (array_contains_element (...)) ...

Entonces, para reafirmar la pregunta, ¿todos quieren decir afirmación cuando dicen pregunta ?


3
¿No se convierten en preguntas todas estas cosas que usted llama aserciones al agregar un signo de interrogación? ¿Key_Exists?
Pieter B

1
'Jon Skeet es asombroso' es una afirmación. '¿Jon Skeet es genial?' es una pregunta. Ver la diferencia. ¿Ver la diferencia?
Steven A. Lowe

@Pieter, no, no en inglés. El signo de interrogación hace una oración una pregunta?
Rick

@ Steven, creo que mi primer ejemplo aborda la primera mitad de tu comentario, y el segundo ejemplo, la segunda mitad. ¿Me estoy perdiendo algo?
Rick

@rick: una afirmación debe ser verdadera, de lo contrario el programa está en un estado indefinido / error. Una pregunta puede o no ser cierta. Pienso en ello como falla de control versus flujo de control.
Steven A. Lowe

Respuestas:


13

El objetivo de las convenciones de nomenclatura no es hacer que su código se lea como inglés, por lo que podría estar analizando en exceso un poco. En muchos idiomas, es habitual prefijar un método o función que devuelve un resultado booleano o una variable booleana is, cuando tiene sentido. Hay otras tradiciones (por ejemplo, Lisp, Ruby), donde ?se usa un sufijo en su lugar. (Una tradición más antigua de Lisp es el sufijo -ppara predicado ).

  • En su ejemplo de transparencia de píxeles, is_transparentdebe ser un método de un objeto de píxeles. Si usted está en un idioma que no tiene objetos, pero desee simular un estilo de programación orientada a objetos, entonces el tipo normalmente sería el prefijo: Pixel_is_transparent. Tenga en cuenta que el prefijo issolo se utiliza para resaltar la naturaleza booleana de este método; ya está implícito en la llamada al método (también pixel.transparentfunciona, pero esto puede volverse demasiado ambiguo con otros nombres de propiedades).
  • Para la prueba de EOF, un método podría ser nombrado at_eof. Esto interpreta el final del archivo como una ubicación en la secuencia, mientras stream.is_eofque también funcionaría: aquí, el EOF es un estado específico.
  • Para probar si existe una entrada, collection.exists(key)sería mejor.
  • array_contains_elementno es un buen nombre de método, ya que contiene un tipo y lo innecesario element. Mejor: array.contains(elem).

Todos los nombres que sugiero son afirmaciones, o más precisamente: predicados. Usar preguntas no tiene ningún sentido lingüístico cuando estos predicados se usan en un contexto si-entonces-otro . La palabra " afirmación " probablemente no es óptima aquí, ya que se utiliza para describir la prueba de invariantes en muchos idiomas. La palabra " predicado " sería mejor: una declaración que sea verdadera o falsa. Una declaración está redactada como si fuera verdad, no como una pregunta. La declaración 1 ∈ {}: " 1es un elemento del conjunto vacío" o "el conjunto vacío contiene 1" es una declaración falsa. La pregunta "¿el conjunto vacío contiene el número 1?" se puede responder con o no, pero no es verdadero o falso.


1
+1 para la nota sobre cómo el término "aserción" no es el término correcto para usar aquí debido a una posible confusión.
Pieter B
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.