¿Por qué algunos programadores experimentados escriben comparaciones con el valor antes de la variable?

Question

Possible Duplicates:
How to check for equals? (0 == i) or (i == 0)
Why does one often see “null != variable” instead of “variable != null” in C#?

He estado teniendo un vistazo a un tutorial aquí y allá, así como un código de DirectX y se dio cuenta de que muchos experimentados programadores de C++ escriben expresiones de la siguiente manera:

(<constant> == <variable>) 

en lugar de lo que mi sabiduría convencional parece preferir:

(<variable> == <constant>) 

Por ej. if (NULL == ptr) en lugar de if (ptr == NULL). Prefiero la segunda alternativa, si no hay otras razones para elegir la primera, mi razón es que la variable parece ser el final "receptor" de la expresión.

Pero sospecho que el primero se usa para evitar asignar inadvertidamente el valor de la constante a la variable usando = en lugar de ==. ¿Sería eso correcto?

Answer 1

Sí, eso es correcto. Es para detectar el error tipográfico de = en lugar de ==.

Answer 2

Evita que escriba var = NULL. Escribir NULL = var arrojará un error. Así que tienes razón :-)

Answer 3

es porque no se puede asignar un valor a una constante, por lo que si por error se pone en lugar de === el compilador emitirá un error al, alertando que

Answer 4

Ese solía ser el caso, sí. Por supuesto, hoy en día casi todos los compiladores advierten sobre las asignaciones en las condiciones if(), por lo que la ventaja solo está ahí para las personas que rutinariamente suprimen las advertencias.

Answer 5

Esa es una justificación común, como lo es el argumento de que no desea empujar la constante hacia la derecha de la pantalla con una expresión larga. Este último argumento nunca ha sonado particularmente convincente para mí, y el primero no es realmente válido en estos días, ya que cualquier compilador que se precie emitirá advertencias (usted compila con warnings-as-errors, ¿no? :-) .

EDIT: ¡Acabo de encontrar la nueva vista previa de Xcode 4, y solo miro el ejemplo que eligieron para ejemplificar su nueva función "Fix-it"!

alt text http://devimages.apple.com/technologies/tools/images/new_autocorrect20100721.jpg

Answer 6

para atrapar la diferencia entre la asignación y la comparación.

Si se refiere a:

if (ptr == foo) 

pero escribir los

if (ptr = foo) 

si todavía será un código válido, ya que ptr = foo se evaluará como un cheque booleano en ptr después de que se ha establecido en el valor de foo. Obviamente, no quieres esto.

Sin embargo, considero que daña considerablemente la legibilidad, y dado que la mayoría de los procesadores IDE y preprocesadores captarán esto de todos modos, nunca use este estilo.

Answer 7

Como desarrollador java tiendo a escribir expresiones como esta:

//primitive check 
    if(constant == variable) 

    //Object check 
    if(constant.equals(variable)) 

Esto es particularmente importante para el objeto debido a que la expresión no hace error si la variable es nula. Si la expresión estuviera en el otro orden, una variable nula sería un error. Mantengo coherencia y hago el mismo orden para los primitivos.

Answer 8

Mira la respuesta de primer nivel a esta pregunta ..

https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Han llamado a este estilo de codificación "Yoda Condiciones".

Answer 9

¡Esto se ha denominado como "Yoda Condicional"!

ve aquí https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

me gusta mucho ese término porque:

if(Light::On == light) 

dice así:

"If on is the light"

Como se ha dicho ya, esto se utiliza para prevenir la asignación incorrecta. Se podría argumentar que esta práctica es arcaica basada en IDEs modernos, pero todavía creo que es una buena práctica.

Answer 10

La asignación de captura es una de las principales razones por las que se usan las condiciones Yoda, pero hay otras: en C++, el operador se invoca en el operando LHS. Como las constantes son típicamente const (duh), o primitivas, esto limita la posibilidad de operaciones no sensoriales. Un ejemplo es = en un literal primitivo, como la razón común dada (1 = a), pero esto incluirá operator=() const, o cualquier operador que se use para tipos que no sean POD.

Answer 11

Con un lenguaje como VB 6.0 que no no tiene asignación distinta y operadores de comparación,

a = 2

'compilará, si nos referimos a una se le asigna 2 o si usted está comparando una con 2 Si quiere decir comparar, existe la posibilidad de que se produzca un error de tiempo de ejecución.

'para la asignación si siempre escribir

a = 2

' Y para Asignación si siempre escribir

2 = a

'se elimina el de compilación éxito y el tiempo de ejecución -Escenario de error.

embargo, esto es sólo la punta: el indicio visual no está disponible cuando se tiene una expresión como

a = b 'Comparación o cesión?

C# tiene: - asignación diferente (=) & comparación (==) símbolos - comparaciones tienen que ser envuelto en paréntesis.

Entonces esto se convierte en un problema.

Answer 12

porque saben lo que están haciendo: P

Answer 13

Tienes razón - es para desencadenar un error de compilación si se escribe incorrectamente "==" como "=", ya que una asignación siempre devolverá verdadero. Si bien esto suele ser fácil de notar y de depuración, de vez en cuando se convertirá en una muy difícil de detectar errores, pensar en esto:

#define OK 2 // Or something... 
[...] 
while(status = OK){ 
    // This loop will never end 
    // Even if you change the value of status within it 
    [...] 
} 

Eso puede ser un error desagradable de encontrar, especialmente si el bloque pertenecer a la declaración ofensiva es larga (imagine buscar todas las posibles razones por las cuales el estado siempre se mantiene bien).

Si por el contrario que utilizó:

while(OK = status){ 

ello equivaldría a un error de compilación, ya que no se puede asignar un valor a una constante.

Esta práctica a veces se conoce como condiciones de Yoda, ya que yuxtapone el objeto y el sujeto. Como "si el estado es correcto" frente a "si OK es el estado" y "el cielo es azul" frente a "azul es el cielo", lo último es algo que Yoda podría decir.