¿Cuál es la diferencia entre estos (bCondition == NULL) y (NULL == bCondition)?

Question

Al explorar sitios msdn, la mayoría de los lugares de comprobación de condición están usando (NULL == bCondition).

¿Cuál es el propósito de usar estas notaciones?

Proporcione alguna muestra para explicar esto por favor.

Gracias.

Answer 1

El uso de NULL == condition proporciona un comportamiento más útil en el caso de un error tipográfico, cuando un operador de asignación = se utiliza accidentalmente algo entonces el operador de comparación ==:

if (bCondition = NULL) // typo here 
{ 
// code never executes 
} 

if (NULL = bCondition) // error -> compiler complains 
{ 
// ... 
} 

C-compilador da una advertencia en la antigua caso, no hay tales advertencias en muchos idiomas.

Answer 2

Muchas personas prefieren escribir NULL == bCondition para que accidentalmente no asignen el valor NULL a bCondition.

Debido errata ocurre que en vez de escribir

bCondition == NULL 

terminan escribiendo

bCondition = NULL // the value will be assigned here. 

En caso de

NULL = bCondition // there will be an error 

Answer 3

Es simplemente una buena medida defensiva. Algunos también pueden encontrar más conveniente para leer. En el caso de una asignación mal escrita en lugar del operador de igualdad, el compilador intentará modificar NULL, que no es un valor l y generará un mensaje de error. Al usar bCondition = NULL, el compilador puede producir una advertencia sobre el uso de una asignación como un valor de verdad, un mensaje que puede perderse y pasar desapercibido.

Answer 4

Se llama Yoda Conditions. (El original link, necesita una alta reputación para verlo).

Está destinado a proteger contra la asignación accidental = en condiciones donde se pretendía una comparación de igualdad ==. Si se adhiere a Yoda por hábito y comete un error al escribir = en lugar de ==, el código no se compilará porque no se puede asignar a un valor r.

¿Vale la pena la incomodidad? Algunos están en desacuerdo, diciendo que los compiladores emiten una advertencia cuando ven = en expresiones condicionales. Digo que simplemente sucedió dos o tres veces en mi vida para cometer este error, lo que no justifica cambiar todos los MLOC que escribí en mi vida a esta convención.

Answer 5

No hay diferencia. Es una antigua forma de programación defensiva que ha quedado obsoleta durante más de 20 años. El objetivo era protegerse de tipeo accidental = en lugar de == cuando se comparan dos valores. Los programadores de Pascal que migraron a C fueron especialmente propensos a escribir este error.

De Borland Turbo C lanzado en 1990 y en adelante, cada compilador conocido advierte contra "asignación posiblemente incorrecta", cuando logra escribir este error.

Así escritura (NULL == bCondición) no es mejor o peor práctica que a la inversa, a menos que su compilador es muy antigua. No necesita preocuparse por escribirlos en un orden en particular.

Lo que debe molestarse con, consiste en adaptar un estilo de codificación donde nunca asignaciones de escritura dentro si/condiciones del bucle. Nunca hay una razón para hacerlo. Es una característica completamente superflua, arriesgada y fea del lenguaje C. Todas las normas de codificación de facto de la industria prohíben la asignación dentro de las condiciones.

Referencias:

• MISRA C: 2,004 13,1
• CERT C EXP18-C

Answer 6

Mientras generalmente no hay diferencia entre variable == value y value == variable, y en principio no shouldn' t ser, en C++ a veces puede haber una diferencia en el caso general si se trata de sobrecarga del operador. Por ejemplo, aunque se espera que == sea simétrico, alguien podría escribir una implementación patológica que no lo es.

La clase de cadena _bstr_t de Microsoft sufre un problema de asimetría en su implementación operator==.