Diferencia nulo

Question

¿Cuál es la diferencia entre

if(null==object) 

y

if(object==null) 

Por favor, dar la ventaja para el uso de los anteriores.

Answer 1

La diferencia viene si accidentalmente escribe = en lugar de ==:

if (null = object) - Compilador de error
if (object = null) - Bug!

Answer 2

Sin diferencia. (null == object) es una práctica de C/C++, donde "=" se usa como operador de asignación y como operador de comparación.

Hubo demasiados errores cuando se utilizó if (object = null).

Answer 3

Algunos prefieren if (null == object) de modo que si accidentalmente ingresa = en lugar de ==, se obtiene un error de compilación en lugar de una asignación.

Answer 4

Lógicamente, no hay diferencia.

De un error comprobar punto de vista, la primera es más deseable porque si se olvida de un signo igual (=), el compilador le hará saber que no se puede realizar una asignación a una constante.

Answer 5

En muchos idiomas == es el operador de comparación = es el operador de asignación.

Es muy fácil escribir = cuando realmente quieres decir ==.

Por lo tanto, se prefiere la convención de escribir constante == variable.

constante = variable no se compilará mostrando su error.

variable = constante compilará y hará lo incorrecto en el tiempo de ejecución.

Answer 6

Bueno, aquí es algo que me gusta ... extensiones de uso:

public static class ObjectExtensions 
{ 
    public static bool IsNull(this object target) 
    { 
     return null == target; 
    } 
} 

Ahora, usted puede olvidarse de él por completo:

if(item.IsNull()) 

Answer 7

En los viejos tiempos, los compiladores felizmente le permite hacer asignaciones dentro de condicionales, lo que lleva a errores involuntarios:

if(a = false) 
{ 
    // I'll never execute 
} 
if(b = null) 
{ 
    // I'll never execute 
} 
b.Method(); // And now I'm null! 

Así que algunos desarrollos inteligentes rs comenzó a poner sus constantes primero en sus condicionales:

if(false = a) // OOPS! Compiler error 
{ 
    // .. 
} 
if(null = b) // OOPS! Compiler error 
{ 
    // .. 
} 

De modo que se entrenaron para evitar una clase completa de errores. La mayoría de los compiladores modernos ya no le permitirán cometer ese error, pero la práctica continúa.

Hay otra ventaja para siempre poniendo primero sus constantes:

if(myString != null && myString.Equals("OtherString")) 
{ 
    // ... 
} 

puede (en .NET, Java, y la mayoría de los idiomas con un tipo de cadena basado en objetos) se reducirá a:

if("OtherString".Equals(myString)) 
{ 
    // .. 
}