¿No “if (0 == value)…” hace más daño que bien? [cerrado]

Ah, sí, "condicionales de Yoda" ("Si el valor es cero, ejecuta este código, ¡debes hacerlo!"). Siempre señalo a cualquiera que diga que es "mejor" en herramientas como la pelusa (1). Este problema particular ha sido resuelto desde finales de los 70s. 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.

Las personas leen de izquierda a derecha en prácticamente todos los lenguajes de programación (y en 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. Sólo ahora tengo el contexto.
• Vuelve a reconsiderar 123 y por qué x se compara con él.

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

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

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

Poner el valor primero puede ser una buena idea si quiere llamar la atención sobre él, por ejemplo. %código%. Normalmente esta no es la intención.

¿Dañino? No. Funciona de cualquier manera.

¿Mala práctica? Debatable, en el mejor de los casos. Es una 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. Simple.

¿Más palabras?

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

"No deberías olvidar" - bueno duh - no, por supuesto que no deberías estar cansado, he estado programando todo el día, he tenido que usar dos idiomas diferentes Y a veces, solo a veces, siendo humano me equivoco.

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 fallar ... 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 (lo que hace todo tipo de suposiciones erróneas) pero que el programador decente no puede leer 0 == valor ??

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

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

Nunca sentí que todo el '¿qué pasa si olvido a =?' Alguna vez realmente sostuvo mucho peso. Sí, puedes hacer un error tipográfico, pero todos hacemos errores tipográficos, parece tonto cambiar todo tu estilo de codificación porque tienes miedo de cometer un error. ¿Por qué no hacer todas tus variables & ¿Funciona todo en minúsculas sin puntuación, porque podría olvidarse de poner algo en mayúscula o olvidar un guión bajo algún día?

Algunas personas lo usan para dejar en claro qué hace exactamente 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 los argumentos en reversa ilustran el punto de una prueba (condicional) antes de la prueba en sí.

En toda la actualidad, realmente no me importa de ninguna manera. Tengo mis problemas con el estilo y la más grande es la inconsistencia. Entonces, hazlo de la misma manera, de manera consistente y no me importará leer tu código.

Combínalo hasta el punto en el que parece que seis personas diferentes con su propio estilo distintivo trabajaron en ello a la vez, me molesta un poco.

Para mí, es un condicionamiento simple. Como alguien que aprendió (en los años 90) C y C ++, me acostumbré y todavía lo utilizo, a pesar de que las razones están aprendidas.

Una vez que estés "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 donde la parte variable de 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 con puntos tienen los mejores ejemplos de esto.

Por ejemplo, algo en lo que trabajé con el inicio de sesión único tenía una situación en la que se podían tener dos sesiones simultáneas si ocurría un cierto tipo de error y se recuperaba de cierta manera, así que tengo que agregar un manejador que estaba dentro de un si eso fuera algo como esto:

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

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

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

Lo sostengo un poco. El consejo que he seguido (posiblemente de Code Complete) es mantener el valor más bajo a la izquierda en las comparaciones. Estaba discutiendo esto con un colega antes y él pensó que era un poco loco, pero me he acostumbrado mucho.

Así que diría:

if ( 0 <= value )

Pero también diría:

if ( value <= 100 )

Igualidad Tendré a verificar con la variable de la izquierda, aunque es más legible.