example - string equals java

Java: "xx".equals(variable) mejor que variable.equals("xx"), TRUE?

Question

Estoy revisando un manual de mejores prácticas y recomendaciones de codificación de Java que creo que es dudoso.

Recomendación:

String variable;

"xx".equals(variable) // OK

variable.equals("xx") //Not recomended

Porque evita la aparición de NullPointerException que no están controladas.

¿Es esto cierto?

Answer 1

Como nota al margen, aquí hay un patrón de diseño donde esta recomendación de código podría no hacer ninguna diferencia, ya que la Cadena (es decir, Optional<String> ) nunca es nula debido a la llamada .isPresent () del patrón de diseño:

Optional<String> gender = Optional.of("MALE");
if (gender.isPresent()) {
    System.out.println("Value available.");
} else {
    System.out.println("Value not available.");
}
gender.ifPresent(g -> System.out.println("Consumer: equals: " + g.equals("whatever")));

Answer 2

En realidad, creo que la recomendación original es cierta. Si usa variable.equals("xx") , obtendrá una NullPointerException si la variable es nula. Poner la cadena constante en el lado izquierdo evita esta posibilidad.

Depende de usted si esta defensa vale la pena por lo que muchas personas consideran un lenguaje antinatural.

Answer 3

Es cierto que usar cualquier propiedad de un objeto de esa manera te ayuda a evitar la NPE.

Pero es por eso que tenemos Excepciones, para manejar ese tipo de cosas.

Tal vez si usas "xx" .equals (variable) nunca sabrías si el valor de la variable es nulo o simplemente no es igual a "xx". En mi opinión, es mejor saber que está obteniendo un valor nulo en su variable, por lo que puede reasignarlo, en lugar de simplemente ignorarlo.

Answer 4

Es verdad. Si la variable es null en tu ejemplo,

variable.equals("xx");

lanzará un NPE porque no puede llamar a un método ( equals ) en un objeto nulo. Pero

"xx".equals(variable);

sólo devolverá false sin error.

Answer 5

Esta es una técnica común utilizada en los programas Java (y C #). La primera forma evita la excepción de puntero nulo porque se llama al método .equals() en la cadena constante "xx" , que nunca es nula. Una cadena no nula comparada con una nula es falsa.

Si sabe que la variable nunca será nula (y su programa es incorrecto de alguna otra manera si alguna vez es nula), entonces usar variable.equals("xx") está bien.

Answer 6

Esta es una técnica muy común que hace que la prueba devuelva falso si la variable es nula en lugar de lanzar una NullPointerException . Pero supongo que seré diferente y decir que no consideraría esto como una recomendación que siempre debería seguir.

• Definitivamente creo que es algo que todos los programadores de Java deben tener en cuenta, ya que es un lenguaje común.
• También es una técnica útil para hacer que el código sea más conciso (puede manejar el caso nulo y no nulo al mismo tiempo).

Pero:

• Hace que su código sea más difícil de leer: "Si el cielo es azul ..."
• Si acaba de verificar que su argumento no es nulo en la línea anterior, entonces es innecesario.
• Si olvidó realizar la prueba de nulo y alguien viene con un argumento nulo de que no lo esperaba, entonces una NullPointerException no es necesariamente el peor resultado posible. Pretender que todo está bien y llevar hasta que finalmente falle más tarde, no es realmente una mejor alternativa. Fallar rápido es bueno.

Personalmente , no creo que el uso de esta técnica deba ser requerido en todos los casos. Creo que debería dejarse a criterio del programador caso por caso. Lo importante es asegurarse de que ha manejado el caso nulo de una manera adecuada y cómo hacerlo depende de la situación. Verificar el manejo correcto de los valores nulos podría ser parte de las pautas de prueba / revisión de código.

Answer 7

Si necesita comprobar si es null , me parece que esto es más legible que if (variable != null && variable.equals("xx")) . Es más una cuestión de preferencia personal.

Answer 8

Usted tiene razón sobre el orden de la verificación: si la variable es nula, llamar a .equals en la cadena constante evitará un NPE, pero no estoy seguro de que esto sea una buena idea; Personalmente lo llamo "slop".

Slop es cuando no se detecta una condición anormal pero, de hecho, se crean hábitos para evitar personalmente su detección. Pasar alrededor de un nulo como una cadena durante un período prolongado de tiempo conducirá eventualmente a errores que pueden ser oscuros y difíciles de encontrar.

La codificación para la pendiente es lo opuesto a "Fallo rápido falla difícilmente".

El uso de un valor nulo como una cadena puede ocasionalmente ser un gran valor "Especial", pero el hecho de que esté tratando de compararlo con algo indica que su comprensión del sistema es incompleta (en el mejor de los casos), cuanto antes lo descubra. , el mejor.

Por otro lado, hacer que todas las variables sean definitivas de manera predeterminada, usar Genéricos y minimizar la visibilidad de todos los objetos / métodos son hábitos que reducen la pendiente.