2011-12-21 19 views
5

¿Hay alguna diferencia al comparar una variable con null o al comparar null con una variable?(a! = Null) o (null! = A)

Por ejemplo, ¿qué comparación es mejor (a != null) o (null != a)? He leído en alguna parte que el segundo es más rápido pero no encontré el motivo para esto.

+5

Condiciones Yoda FTW :) http://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined (enlace accesible solo para 10k usuarios) –

Respuesta

25

No, ninguno es más rápido. Esa es una simple mentira. No hay ninguna ventaja de usar la segunda versión. Solo empeorando la legibilidad.

Todo esto vino de C, donde se puede escribir erróneamente

if(x = 3) 

en lugar de

if(x == 3) 

Algunas personas pensaron que sería mejor para escribir la primera constante, en cuyo caso si escribió = en lugar de ==, obtendría un error de compilación. Por lo que algunas fuentes recomiendan escribir

if(3 == x) 

Algunas personas no saben qué esto era necesario y continuado y generalizado esta idea a las construcciones y los idiomas en los que no tiene ningún sentido. IMO tampoco tenía mucho sentido en el contexto original de C, pero es una cuestión de gusto personal.

+0

+1 para una buena explicación. – Rudy

+0

Muy claramente explicado, gracias! –

+0

En realidad, * hay * una diferencia de velocidad. Probar 'null == var' es una instrucción más lenta, porque el nulo debe ser empujado a la pila. No mucho, pero tampoco idéntico. – Bohemian

0

No, no hay diferencia alguna.

9

Incluso si hay fueron una diferencia en la velocidad, espero que sea totalmente insignificante en el 99,99% de las aplicaciones. Tal como están las cosas, no esperaría que hubiera ninguna diferencia de velocidad. Personalmente, me resulta más legible if (a != null), y la legibilidad es mucho más importante que el rendimiento en la mayoría de los casos.

+0

bien, me parece 'null! = A' más legible, por costumbre :-) – aishwarya

+4

@aishwarya: ¿un hábito desarrollado a partir de C o C++? Puede ser lógico usar comparaciones de esa manera para estar a la defensiva (aunque los compiladores modernos eligen la asignación accidental, IIRC) pero creo * que la mayoría de los desarrolladores que no tienen un fondo donde hay un beneficio definitivo encuentran la forma "variable primero" más legible –

+0

@JonyAdamit usted gana –

3

Esto normalmente se hace para evitar que la asignación accidentales en lugar de la comparación:

(a = null) //will not give error 

(null = a) //will give error 

estoy bastante seguro de que la eficiencia no es una razón, y si lo fuera, un optimizador haría que el código de la misma en el sistema binario.

+1

No podemos cometer este error en Java, pero C/C++ –

+0

@ H3S No entiendo. –

+0

¡Ah! Quise decir que ambas declaraciones serán un error debido al compilador de Java. 'if (a = null)' bien en algún compilador de C/C++. –

0

no realmente, no en java ahora de todos modos. en días anteriores, puede ser C, podrías olvidar accidentalmente el signo de exclamación y el código compilaría bien. Básicamente, a = null se tomaría como una expresión que asignó null al a y siempre se evalúa como verdadera (porque la asignación fue exitosa).

Los compiladores de hoy en día son mucho más robustos. Aunque los viejos hábitos son difíciles de escribir y todavía escribo null != a :-)

+0

Lamentamos haber llegado tan tarde a la conversación, pero su observación acerca de "una expresión que asignó null a' a' y siempre evalúa como verdadera (porque la asignación fue exitosa) "no es correcta. Se evalúa como cualquiera sea el valor de null (por lo que puede ser falso si null es falso). –

4

Es posible que solo desee utilizar un literal antes de la variable al realizar operaciones con cadenas.

if("abcd".equals(name)) no lanza un NPE donde como if(name.equals("abcd")) hace en todo caso name iban a ser null.