2009-02-27 45 views
15

Son estos equivalentes:C#: Comparando con nula

if (null==myobject) 
{ 
//do something 
} 

y

if (myobject==null) 
{ 
//do something 
} 

o van a producir un código diferente?

+10

El primero es también conocido como el condtion Yoda :) –

Respuesta

41

En el caso del 99%, este código es equivalente.

La única excepción es cuando el tipo del objeto en cuestión anula el operador ==. Es posible que se introduzca un error en == que causa problemas cuando un parámetro es nulo.

Un ejemplo particular que he visto antes es la siguiente

public static bool operator==(Student left, Student right) { 
    return left.Equals(right); 
} 

Este fallará cuando es nula a la izquierda, pero probablemente no cuando nulo en la derecha.

Sin embargo, este es un caso bastante alejado.

+0

La solución es: 'if ((object) left == null)' or 'if (ReferenceEquals (left, null))'. El primero es quizás más eficiente. – yfeldblum

+0

@Justice, nunca he investigado el JIT, pero si lo hace Object.Reference es igual, C# generará una llamada a método. En la ausencia de un operador == C# generará una comparación de valor directo con el código de operación IL ceq. Mi suposición es que el ceq es más rápido. – JaredPar

+4

@Justice, pero nunca asuma nada sobre el rendimiento, confíe en el generador de perfiles :) – JaredPar

9

La forma de la declaración "if" que coloca la constante a la izquierda es un remanente de C/C++ donde podría tener una expresión arbitraria en una instrucción if.

La sintaxis de C# para las sentencias if requiere que la expresión se evalúe en un bool, lo que significa que if (foo = 0) no se compilará.

+0

Oh bien. Recordaba hace un par de años, cuando estaba aprendiendo C#, y había jurado que recordaba haber recibido una advertencia o un error del compilador al usar la asignación (por accidente) en una instrucción if, junto con otros dispositivos de seguridad (como un ruptura faltante en una instrucción switch). +1 –

+0

Solíamos hacer eso deliberadamente, para hacer una tarea y verificar el valor al mismo tiempo. El operador de asignación en C++ devuelve el valor asignado. Extraño un poco esa característica, pero fue fácil abusar. – Jasmine

+1

@Jasmine: a veces también uso el constructo; simplemente haz "if ((foo = bar()) == nullptr)". Pero generalmente eso no sobrevive a la revisión del código: se cambia a "foo = bar(); if (foo == nullptr)", que es más limpio en mi humilde opinión. –

6

El

if (null==myobject) { 

es una manera segura de escribir una sentencia if. Viene de C/C++ donde la condición es una expresión evaluada en int. Si el resultado es cero, significa false, cualquier otra cosa es true. Se podría escribir algo así como

if (variable == 1) { 

pero si no te cuidadoso también se puede escribir

if (variable = 1) { 

en el que caso de que tenga una asignación que siempre se evalúa a 1 y por lo tanto siempre es cierto.

Puede compilar esto y ejecutarlo sin problemas, pero el resultado no será el esperado. Así que los programadores de C/C++ comenzaron a escribir cosas como

if (1 == variable) { 

Esto no se compilará si se escribe incorrectamente, por lo que siempre tenía que escribirlo como que quería decir que escribirlo. Esto luego se convierte en un (buen) hábito y lo usa en todos los idiomas que programa, C# por ejemplo.

2

Para aquellos que lo pierda, de si usted está buscando para reducir el desorden, también es posible activar C-language al estilo nula de comprobación para sus C# clases:

class MyObj 
{ 
    public void implicit_null_comparison_demo() 
    { 
     MyObj mo = null; 
     // ... 

     if (mo)   // <-- like so (can also use !mo) 
     { 
      // it's not null... 
     } 
     else 
     { 
      // it's null... 
     } 
    } 

    public static implicit operator bool(MyObj mo) 
    { 
     return (Object)mo != null; 
    } 
};