objeto == nulo o nulo == objeto?

Escuché de alguien que null == objectes mejor que object == null chequear

p.ej :

void m1(Object obj ) {
   if(null == obj)  // Is this better than object == null ? Why ?
       return ;
   // Else blah blah
}

¿Hay alguna razón o esto es otro mito? Gracias por la ayuda.

Este es probablemente un hábito aprendido de C, para evitar este tipo de error tipográfico (simple en =lugar de doble ==):

if (object = null) {

La convención de poner la constante en el lado izquierdo de ==no es realmente útil en Java, ya que Java requiere que la expresión en una ifevaluación sea un booleanvalor, por lo que, a menos que la constante sea a boolean, obtendría un error de compilación de cualquier manera que ponga el argumentos. (y si es un booleano, no deberías usarlo de ==todos modos ...)

Como han dicho otros, es un hábito aprendido de C para evitar errores tipográficos, aunque incluso en C, esperaría compiladores decentes con niveles de advertencia lo suficientemente altos como para dar una advertencia. Como dice Chandru, comparar con nulo en Java de esta manera solo causaría problemas si estuviera usando una variable de tipo Boolean(que no está en el código de muestra). Yo diría que es una situación bastante rara, y no una para la que vale la pena cambiar la forma en que escribe el código en cualquier otro lugar. (No me molestaría en invertir los operandos incluso en este caso; si estoy pensando con la suficiente claridad como para considerar invertirlos, estoy seguro de que puedo contar los signos iguales).

Lo que no se ha mencionado es que muchas personas (incluido yo mismo) encuentran que el if (variable == constant)formulario es más legible, es una forma más natural de expresarse. Esta es una razón para no copiar ciegamente una convención de C. Siempre debe cuestionar las prácticas (como lo está haciendo aquí :) antes de asumir que lo que puede ser útil en un entorno es útil en otro.

Esto no tiene mucho valor en Java (1.5+) excepto cuando el tipo de objeto es Boolean. En cuyo caso, esto aún puede ser útil.

if (object = null)no causará fallas de compilación en Java 1.5+ si el objeto es, Booleanpero lanzaría un NullPointerExceptionen tiempo de ejecución.

En Java no hay una buena razón.

Un par de otras respuestas han afirmado que se debe a que accidentalmente puede asignarlo en lugar de igualdad. Pero en Java, debe tener un booleano en un if, así que esto:

if (o = null)

no se compilará.

La única vez que esto podría importar en Java es si la variable es booleana:

int m1(boolean x)
{
    if (x = true)  // oops, assignment instead of equality

Esto también se relaciona estrechamente con:

if ("foo".equals(bar)) {

lo cual es conveniente si no desea tratar con NPE:

if (bar!=null && bar.equals("foo")) {

Este truco se supone que evita v = nullerrores tipográficos.

Pero Java solo permite expresiones booleanas como if()condiciones, por lo que ese truco no tiene mucho sentido, el compilador encontrará esos errores tipográficos de todos modos.

Sin embargo, sigue siendo un truco valioso para el código C / C ++.

Por la misma razón lo haces en C; La asignación es una expresión, por lo que coloca el literal a la izquierda para que no pueda sobrescribirlo si accidentalmente usa en =lugar de ==.

Eso es para personas que prefieren tener la constante en el lado izquierdo. En la mayoría de los casos, tener la constante en el lado izquierdo evitará que se lance NullPointerException (o tener otro nullcheck). Por ejemplo, el método String equals también realiza una comprobación nula. Tener la constante a la izquierda le impedirá escribir el cheque adicional. Lo cual, de otra manera también se realiza posteriormente. Tener el valor nulo a la izquierda es simplemente ser consistente.

me gusta:

 String b = null;
 "constant".equals(b);  // result to false
 b.equals("constant");  // NullPointerException
 b != null && b.equals("constant");  // result to false

Es la condición de Yoda escribiendo de manera diferente.

En java

String myString = null;
if (myString.equals("foobar")) { /* ... */ } //Will give u null pointer

condición de yoda

String myString = null;
if ("foobar".equals(myString)) { /* ... */ } // will be false 

Compare con el siguiente código:

    String pingResult = "asd";
    long s = System.nanoTime ( );
    if ( null != pingResult )
    {
        System.out.println ( "null != pingResult" );
    }
    long e = System.nanoTime ( );
    System.out.println ( e - s );

    long s1 = System.nanoTime ( );
    if ( pingResult != null )
    {
        System.out.println ( "pingResult != null" );
    }
    long e1 = System.nanoTime ( );
    System.out.println ( e1 - s1 );

Salida (después de varias ejecuciones):

null != pingResult
325737
pingResult != null
47027

Por tanto, pingResult != nulles el ganador.

Debido a su propiedad conmutativa , la única diferencia entre object == nully null == object(la versión de Yoda ) es de naturaleza cognitiva : cómo el lector lee y digiere el código. Sin embargo, no sé la respuesta definitiva, pero sé que personalmente prefiero comparar el objeto que estoy inspeccionando con otra cosa, en lugar de comparar otra cosa con el objeto que estoy inspeccionando , si eso tiene algún sentido. Comience con el tema, luego el valor con el que compararlo.

En algunos otros idiomas, este estilo de comparación es más útil.

Sin embargo, para protegerse contra un signo "=" perdido en general, creo que escribir null == objectes un acto equivocado de programación defensiva . La mejor forma de evitar este código en particular es garantizando el comportamiento con una prueba junit. Recuerde, el posible error de perder un "=" no depende de los argumentos de entrada del método; usted no depende del uso correcto de esta API por parte de otras personas, por lo que una prueba junit es perfecta para protegerse contra eso. De todos modos, querrá escribir pruebas junit para verificar el comportamiento; un "=" faltante naturalmente cae dentro del alcance.