java - true - if(boolean== false) vs. if(! boolean)

true false java

Question

Posible duplicado:
¿Es malo comparar explícitamente contra constantes booleanas, por ejemplo, si (b == falso) en Java?

En este código de ejemplo de NotePadProvider , noté que el autor eligió el formulario:

 if (values.containsKey(NoteColumns.CREATED_DATE) == false) {
values.put(NoteColumns.CREATED_DATE, now);
}

Encima:

 if (!values.containsKey(NoteColumns.CREATED_DATE)) {
values.put(NoteColumns.CREATED_DATE, now);
}

¿Hay alguna ventaja en la primera forma sobre la más lógica?

Answer 1

Además de la "legibilidad", no. Son funcionalmente equivalentes.

_{(La "legibilidad" está entre comillas porque odio == false y encuentro ! Mucho más legible. Pero otros no).}

Answer 2

Esta es una elección de estilo. No afecta el rendimiento del código en lo más mínimo, solo lo hace más detallado para el lector.

Answer 3

La primera forma, cuando se usa con una API que devuelve Boolean y se compara con Boolean.FALSE, nunca lanzará una NullPointerException .

La segunda forma, cuando se usa con la interfaz java.util.Map , tampoco arrojará una NullPointerException porque devuelve un boolean y no un Boolean .

Si no le preocupan los lenguajes de codificación coherentes, puede elegir el que más le guste, y en este caso concreto realmente no importa. Si le importa una codificación consistente, entonces considere lo que quiere hacer cuando selecciona un Boolean que puede ser NULL .

Answer 4

Mayormente LEYENDA. Al leer código de otros, es mucho más intuitivo leer que NOT CONTAINS KEY !values.containsKey(NoteColumns.CREATED_DATE) lugar de leer CONTAINS KEY IS FALSE (values.containsKey(NoteColumns.CREATED_DATE) == false) .

Answer 5

No. No veo ninguna ventaja. El segundo es más estrecho.

Por cierto: el segundo estilo se encuentra en cada esquina de la fuente JDK.

Answer 6

Nota: Con ConcurrentMap puede usar el más eficiente

values.putIfAbsent(NoteColumns.CREATED_DATE, now);

Prefiero la solución menos verbosa y evito métodos como IsTrue o IsFalse o sus similares.

Answer 7

- Aquí se trata más del coding style que de la funcionalidad ...

- La primera opción es muy clara , pero la segunda es bastante elegante ... sin ofender, es solo mi opinión ...