¿Por qué uno a menudo ve “null! = Variable” en lugar de “variable! = Null” en C #?

En c #, ¿hay alguna diferencia en la velocidad de ejecución para el orden en que declaras la condición?

if (null != variable) ... if (variable != null) ... 

Desde hace poco, vi la primera con bastante frecuencia, y me llamó la atención ya que estaba acostumbrado a la segunda.

Si no hay diferencia, ¿cuál es la ventaja de la primera?

Es una retención de C. En C, si usa un comstackdor incorrecto o no tiene las advertencias suficientemente altas, se comstackrá sin advertencia alguna (y es, de hecho, código legal):

 // Probably wrong if (x = 5) 

cuando en realidad probablemente quiso decir

 if (x == 5) 

Puede solucionar esto en C haciendo:

 if (5 == x) 

Un error tipográfico dará como resultado un código inválido.

Ahora, en C #, esto es todo pifia. A menos que esté comparando dos valores booleanos (lo cual es raro, IME) puede escribir el código más legible, ya que una statement “if” requiere una expresión booleana para comenzar, y el tipo de ” x=5 ” es Int32 , no Boolean

Sugiero que si ves esto en el código de tus colegas, los eduques en las formas de los idiomas modernos, y sugieres que escriban la forma más natural en el futuro.

Hay una buena razón para usar null primero: if(null == myDuck)

Si su class Duck anula el operador == , entonces if(myDuck == null) puede entrar en un ciclo infinito.

El uso de null primero usa un comparador de igualdad predeterminado y realmente hace lo que se proponía.

(He oído que te acostumbras a leer el código escrito de esa manera con el tiempo, pero aún no he experimentado esa transformación).

Aquí hay un ejemplo:

 public class myDuck { public int quacks; static override bool operator ==(myDuck a, myDuck b) { // these will overflow the stack - because the a==null reenters this function from the top again if (a == null && b == null) return true; if (a == null || b == null) return false; // these wont loop if (null == a && null == b) return true; if (null == a || null == b) return false; return a.quacks == b.quacks; // this goes to the integer comparison } } 

Supongo que este es un progtwigdor de C que ha cambiado de idioma.

En C, puede escribir lo siguiente:

 int i = 0; if (i = 1) { ... } 

Observe el uso de un solo signo igual allí, lo que significa que el código asignará 1 a la variable i, luego devolverá 1 (una asignación es una expresión), y usará 1 en la instrucción if, que se manejará como verdadera. En otras palabras, lo anterior es un error.

En C # sin embargo, esto no es posible. De hecho, no hay diferencia entre los dos.

Como todos ya han notado, proviene más o menos del lenguaje C, donde puedes obtener un código falso si accidentalmente olvidas el segundo signo de igual. Pero hay otra razón que también coincide con C #: Legibilidad.

Solo toma este simple ejemplo:

 if(someVariableThatShouldBeChecked != null && anotherOne != null && justAnotherCheckThatIsNeededForTestingNullity != null && allTheseChecksAreReallyBoring != null && thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded != null) { // ToDo: Everything is checked, do something... } 

Si simplemente cambiara todas las palabras nulas al comienzo, podrá detectar todas las verificaciones con mayor facilidad:

 if(null != someVariableThatShouldBeChecked && null != anotherOne && null != justAnotherCheckThatIsNeededForTestingNullity && null != allTheseChecksAreReallyBoring && null != thereSeemsToBeADesignFlawIfSoManyChecksAreNeeded) { // ToDo: Everything is checked, do something... } 

Así que este ejemplo es tal vez un mal ejemplo (consulte las pautas de encoding), pero solo piense en su desplazamiento rápido sobre un archivo de código completo. Simplemente viendo el patrón

 if(null ... 

inmediatamente sabes lo que vendrá después.

Si fuera al revés, siempre tiene que escanear hasta el final de la línea para ver la verificación de nulidad, simplemente dejándole tropezar por un segundo para averiguar qué tipo de control se realiza allí. Entonces, tal vez el resaltado de syntax lo ayude, pero siempre es más lento cuando esas palabras clave se encuentran al final de la línea en lugar de al frente.

En tiempos pasados, la gente olvidaba el ‘!’ (o el extra ‘=’ para la igualdad, que es más difícil de detectar) y hacer una tarea en lugar de una comparación. poner el nulo al frente elimina la posibilidad del error, ya que null no es un valor l (IE no se puede asignar a).

La mayoría de los comstackdores modernos dan una advertencia cuando realizas una asignación en un condicional hoy en día, y C # en realidad da un error. La mayoría de la gente simplemente se queda con el esquema var == nulo, ya que es más fácil de leer para algunas personas.

No veo ninguna ventaja en seguir esta convención. En C, donde los tipos booleanos no existen, es útil escribir

 if( 5 == variable) 

más bien que

 if (variable == 5) 

porque si olvidas uno de los signos eaqual, terminas con

 if (variable = 5) 

que asigna 5 a variable y siempre evalúa a verdadero. Pero en Java, un booleano es un booleano. Y con! =, No hay ninguna razón en absoluto.

Un buen consejo, sin embargo, es escribir

 if (CONSTANT.equals(myString)) 

más bien que

 if (myString.equals(CONSTANT)) 

porque ayuda a evitar NullPointerExceptions.

Mi consejo sería pedir una justificación de la regla. Si no hay ninguno, ¿por qué seguirlo? No ayuda a la legibilidad

Para mí, siempre ha sido el estilo que prefieres

@Shy – Por otra parte, si confundes a los operadores, entonces deberías querer obtener un error de comstackción o estarás ejecutando código con un error, un error que regresa y te muerde más adelante porque produjo un comportamiento inesperado.

Una cosa más … Si está comparando una variable con una constante (entero o cadena por ejemplo), poner la constante a la izquierda es una buena práctica porque nunca se encontrará con NullPointerExceptions:

 int i; if(i==1){ // Exception raised: i is not initialized. (C/C++) doThis(); } 

mientras

 int i; if(1==i){ // OK, but the condition is not met. doThis(); } 

Ahora, dado que de forma predeterminada C # instancia todas las variables, no debería tener ese problema en ese idioma.