2011-02-10 22 views

Respuesta

7

La diferencia aquí es el código generado . Los dos no generarán exactamente el mismo código, pero en la práctica esto no afectará los resultados o el rendimiento de las dos declaraciones.

Sin embargo, si crea sus propios tipos y anula el operador de desigualdad y hace un trabajo pobre, entonces será importante.

Considera:

public class TestClass 
{ 
    ... 

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

En este caso, si el primer argumento para el operador es nulo, es decir. if (null != obj), luego se bloqueará con un NullReferenceException.

Entonces, para resumir:

  • el código generado es diferente
  • el rendimiento y los resultados finales deben ser los mismos
    • Excepto cuando se ha roto el código en el tipo implicado

Ahora, la razón por la que creo que estás preguntando es que has visto el código de C, w HICH normalmente tenía código como este:

if (null == obj) 

Tenga en cuenta que me pasa a comprobación de igualdad aquí. La razón es que un error frecuente en programas escritos con viejos compiladores de C (estos días tienden a detectar este problema) sería cambiarlo y olvidar uno de los caracteres iguales, es decir. esto:

if (obj = null) 

Esto asigna a la variable null en lugar de compararlo. La mejor manera de combatir este error, en aquel entonces, sería cambiarlo, ya que no puedes asignar nada al null, no es una variable. es decir. esto sería un fracaso para compilar:

if (null = obj) 
2

No, no lo hay. Es exactamente lo mismo.

El estilo null == obj a veces solo se usa para evitar que el error tipográfico obj = null no asigne accidentalmente nulo a una variable, pero con != no hay absolutamente ninguna razón para hacerlo.

En .NET no se compilará para el error tipográfico obj = null.
Así que el compilador evita que accidentalmente lo haga.

El Yoda condition viene originalmente de otros idiomas, donde falta esta característica del compilador.

+0

Y el compilador le advertirá si accidentalmente utiliza '=' en lugar de '=='. – LukeH

+0

Sí, solo iba a agregar eso para .NET. –

+0

no son exactamente lo mismo, si obj anula al operador en cuestión, el resultado puede ser diferente. – Massif

4

No, pero la segunda forma es más común y más fácil de leer (y más lógico en mi opinión)

20

La primera es una condición Yoda. Úselo, no debería.

1

Son exactamente lo mismo.

Algunas personas prefieren poner la hipótesis nula como la primera parte de la expresión para evitar errores como este

if (obj = null) // should be obj == null 

Pero por supuesto, esto no se aplica al operador !=, por lo que en su ejemplo que sólo una diferencia de estilo

+0

y en C# if (obj = null) es un error de compilación, porque "obj = null" no se evalúa como booleano. – Massif

0

El uso de la primera forma

if (blah == obj) 

proviene de los días en que los compiladores no coger if (obj = blah) es decir, la asignación involuntaria, a menos que el nivel de advertencia de compilación se ajusta al máximo

0

primer tipo de declaración se produjo a partir C/C++, donde era posible pasar no valores booleanos para condicionar la verificación. P.ej. todo lo que no 0 era cierto, y el cero era falsa:

if (5) { } // true 
if (0) { } // false 

A veces se crean problemas si se olvidó de escribir un '=' Char:

if (x = 5) { } // this was true always and changed x value 
if (x == 5) { } // this was true, if x was equal to 5 

Por lo tanto, se utilizó la sintaxis Yoda, para recibir compilador error en caso de que uno '=' se perdió:

if (5 = x) { } // this was generating compiler error for absent-minded programmers 
if (5 == x) { } // this was true, if x was equal to 5 

C# permiten sólo un valor booleano en condiciones, tanto

if (x = 5) { } // this won't compile 
if (x == 5) { } // this is true, if x was equal to 5 

¿Qué pasa con los tipos booleanos?

if (y = true) { } 
if (y == true) { } 

Pues bien, este es el código inútil, ya que sólo puede escribir si (y). Conclusión: la sintaxis de Yoda se ha ido con C/C++ y ya no necesita usarla.