Método booleano Nomenclatura afirmativa vs negativa


44

¿Deberían los métodos booleanos tomar siempre la forma afirmativa, incluso cuando solo se utilizarán en forma negativa?

Digamos que quería verificar si existe una entidad antes de crear una, mi argumento es que la primera forma a continuación es mejor que la segunda forma, ya sea que el método se use o no en forma afirmativa.

En resumen, me resulta if(!affirmative)más fácil de leer que if(negative). Tengo un colega que no está de acuerdo, ¿pensamientos?

Primera forma:

int entity_id = 42;
if(!entity_exists(entity_id)) create_entity(entity_id);

Segunda forma:

int entity_id = 42;
if(entity_not_exist(entity_id)) create_entity(entity_id);

3
C ++? ¿ if (not entity_exists(entity_id))
Qué tal


a-mayo-a-mah-a. Honestamente, he extrañado el !personaje tantas veces que me hizo entender mal el código hasta que lo volví a leer. Así que probablemente estoy más de acuerdo con tu compañero de trabajo. Me gusta la forma que se evalúa como verdadera cuando la examinas.
Berin Loritsch

Solo quería intervenir para decir que if (!exists) create()puede verse como una mala práctica en muchos lenguajes / marcos, ya que tiende a no ser seguro para subprocesos. Por lo general, el enfoque preferido es llamar create()y manejar excepciones específicas o códigos de retorno que dicen que la entidad ya existe. Por supuesto, esto no es una respuesta a la pregunta real (que es por qué es solo un comentario).
julealgon

Respuestas:


61

¿Deberían los métodos booleanos tomar siempre la forma afirmativa, incluso cuando solo se utilizarán en forma negativa?

Hacer reglas sobre tales cosas parece un poco demasiado: no me gustaría ver una guía en un documento de estándares de codificación que diga que no usará nombres negativos para propiedades booleanas . Pero como cuestión de estilo personal, creo que tratar de mantener los nombres positivos podría ser un excelente ideal. Sin embargo, creo que también es bueno evitar la necesidad de ese flaco y fácil de perder !. A menudo se pueden encontrar formas de convertir un nombre negativo en uno positivo:

  • accountHasCharges
  • accountIsClear(igual que !accountHasCharges)

La claridad es la consideración más importante, y una buena razón para evitar nombres de métodos negativos es que pueden conducir a negativos dobles o peor:

  • isComplete // bueno
  • isNotComplete //! isComplete suele ser mejor
  • isIncomplete // podría tener sentido si 'incompleto' es un estado conocido del objeto
  • !isNotComplete // horrible
  • !isNotComplete == 0 // puede conducir a vacaciones permanentes

55
"No me gustaría ver una guía en un documento de estándares de codificación que diga que no usará nombres negativos para propiedades booleanas ". -
Dejaré

16
Olvidaste!isNotIncomplete
Ben Lee

Entonces, ¿sería lo opuesto a entity_existsser entity_should_be_created(en lugar de entity_not_exists)? ¿O tal vez entity_missingsegún la sugerencia de Dan?
ADTC

1
Aquí es donde un documento de estándares de codificación puede usar la palabra "preferir" en lugar de "debería" o "debe".
Wayne Conrad

15

Estoy de acuerdo en que lo afirmativo es más fácil de leer. Podrías intentar

Tercera forma

int entity_id = 42;
if (entity_is_missing(entity_id)) create_entity(entity_id);

o

Cuarta forma

int entity_id = 42;
if (is_entity_missing(entity_id)) create_entity(entity_id);

2

También depende de cómo se usará su método. Si se va a utilizar tanto en casos afirmativos como negativos, por ejemplo

if (!entity_exists(entity_id)) create_entity(entity_id);

if (entity_exists(entity_id)) publish_entity(entity_id);

Entonces el nombre del método debe ser afirmativo, como el anterior. Si no está seguro de cómo se va a usar, entonces cumpla con lo anterior.

Pero si SOLO se usa en el caso negativo, entonces lo siguiente es aceptable (quizás incluso deseable)

if (entity_not_exists(entity_id)) create_entity(entity_id);

o incluso mejor reformularlo para que sea más afirmativo

if (entity_is_absent(entity_id)) create_entity(entity_id);
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.