¿"If (0 == value) ..." hace más daño que bien? [cerrado]

Esta es una de las cosas que más odio cuando lo veo en el código de otra persona. Sé lo que significa y por qué algunas personas lo hacen de esta manera ("¿y si accidentalmente pongo '=' en su lugar?"). Para mí es muy parecido a cuando un niño baja las escaleras contando los pasos en voz alta.

De todos modos, aquí están mis argumentos en contra:

• Interrumpe el flujo natural de leer el código del programa. Nosotros, los humanos, decimos "si el valor es cero" y no "si el cero es valor".
• Los compiladores modernos te advierten cuando tienes una tarea en tu condición, o en realidad si tu condición consiste solo en esa tarea, lo cual, sí, parece sospechoso de todos modos
• No debe olvidar poner el doble '=' cuando compara valores si es un programador. Es mejor que olvides poner "!" cuando se prueba la no igualdad.

Ah, sí, "condicionales de Yoda" ("¡Si el valor es cero, ejecute este código que debe!"). Siempre apunto a cualquiera que diga que es "mejor" en herramientas como lint (1). Este problema particular se ha resuelto desde finales de los años 70. La mayoría de los lenguajes modernos ni siquiera compilan una expresión como if(x = 10), ya que se niegan a forzar el resultado de la asignación a un booleano.

Como han dicho otros, ciertamente no es un problema, pero provoca un poco de disonancia cognitiva.

Es desagradable porque impone un impuesto mental pequeño, pero notable.

La gente lee de izquierda a derecha en prácticamente todos los lenguajes de programación (y la mayoría de los lenguajes naturales).

Si veo 123 == x, la forma en que lo analizo mentalmente es:

• 123- ¿Y qué? información incompleta
• == - bueno, 123 es 123, por qué probarlo ...
• x- Ok, eso es lo que nos preocupa. Solo ahora tengo el contexto.
• Regrese para reconsiderar 123y por qué x se compara con él.

Cuando veo x == 123el análisis mental es:

• x- Proporciona contexto, sé de qué se trata la condición. Puedo elegir ignorar el resto. Basado en el flujo anterior, tengo una buena idea de por qué y qué vendrá (y me sorprendería si es diferente).
• == - Ya me lo imaginaba.
• 123 - Sip.

La interrupción es pequeña (en un ejemplo simple), pero siempre lo noto.

Poner el valor primero puede ser una buena idea si desea llamar la atención sobre él, por ejemplo if (LAUNCH_NUKES == cmd). Normalmente esta no es la intención.

¿Perjudicial? No. Funciona de cualquier manera.

¿Mala práctica? Debatible, en el mejor de los casos. Es simple programación defensiva.

¿Vale la pena perder el sueño? Nah

Esto es básicamente flaimbait.

No, no hace más daño que bien. Sencillo.

¿Mas palabras?

Argumento del compilador? Erm, ish, tal vez, no confíes demasiado en el cumplidor para salvarte de ti mismo.

"No deberías olvidar" - bueno, duh - no, por supuesto, no deberías mientras tanto estoy cansado, he estado codificando todo el día, he tenido que usar dos idiomas diferentes y, a veces, solo a veces, ser humano lo hago un error.

El punto de este tipo de comportamiento es que es defensivo, no está ahí porque esperas cometer errores más de lo que tienes seguro porque esperas colapsar ... pero si lo haces, es bueno estar cubierto.

¿Difícil de leer? Te estás quejando de que un programador decente debería tener == cableado (que hace todo tipo de suposiciones deficientes) pero que el mismo programador decente no puede leer 0 == valor ??

No hace daño, tiene beneficios potenciales, pregunta tonta, deja que otros lo hagan si quieren y siguen adelante.

No lo llamaría daño, pero es desagradable. Entonces no, no diría que sí.

Nunca he sentido que todo el '¿y si olvido un =?' Alguna vez tuvo mucho peso. Sí, puede hacer un error tipográfico, pero todos hacemos errores tipográficos, parece una tontería cambiar todo el estilo de codificación porque tiene miedo de cometer un error. ¿Por qué no hacer que todas sus variables y funciones estén en minúsculas sin signos de puntuación, porque algún día puede olvidar poner en mayúscula algo u olvidar un guión bajo?

Algunas personas lo usan para dejar en claro exactamente lo que está haciendo un condicional. Por ejemplo:

Camino 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Camino 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Algunas personas sienten que el segundo ejemplo es más conciso, o invertir argumentos ilustra el punto de una prueba (condicional) antes de la prueba misma.

En realidad, no me importa de ninguna manera. Tengo mis manías sobre el estilo y el más grande es la inconsistencia. Entonces, hazlo de la misma manera, de manera consistente y no me importará leer tu código.

Mezclar hasta el punto en que parece que seis personas diferentes con su propio estilo distintivo trabajaron en él de una vez, me molesta un poco.

Para mí, es un simple condicionamiento. Como alguien que aprendió (en los años 90) C y C ++, me acostumbré a ello y aún lo uso, a pesar de que se explican los motivos.

Una vez que está "condicionado" para mirar el lado izquierdo en busca de la "constante", se convierte en una segunda naturaleza.

También lo uso solo para equivalencia (o equivalencia negada), no para mayor / menor que.

Estoy completamente de acuerdo con la respuesta de @ Wonko.

El único caso en el que me parece útil es cuando la parte variable del if es bastante larga y ver los valores hace que el código sea más fácil de leer. Los idiomas de espacio de nombres punteados tienen los mejores ejemplos de esto.

Por ejemplo, algo en lo que trabajé con el inicio de sesión único tuvo una situación en la que podría tener dos sesiones simultáneas si ocurriera un cierto tipo de error y se recuperó de cierta manera, así que tengo que agregar un controlador que estaba dentro y si se veía algo como esto:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Es cierto que en este ejemplo hay otras formas de hacer esto, pero este sería un caso en el que la versión número primero es potencialmente más legible.

Y sin embargo, se producen los errores. Y a veces desea una asignación en un operador de bucle donde de otro modo podría verificar la igualdad, o al menos es una práctica estándar usarla.

De alguna manera lo sostengo. El consejo que he seguido (posiblemente de Code Complete) es mantener lo que debería ser el valor más bajo a la izquierda en las comparaciones. Estuve discutiendo esto con un colega antes y él pensó que era una locura, pero me he acostumbrado mucho.

Entonces yo diría:

if ( 0 <= value )

Pero también diría:

if ( value <= 100 )

Igualdad, tenderé a verificar con la variable de la izquierda, sin embargo, es más legible.