¿Cuáles son las ventajas de aplastar la asignación y la comprobación de errores en una línea?

Question

Esta pregunta está inspirada en this question, que presenta el siguiente fragmento de código.

int s; 
if((s = foo()) == ERROR) 
    print_error(); 

puedo encontrar este estilo difícil de leer y propenso a errores (como la pregunta original demuestra - que fue motivada por paréntesis en torno a la asignación que falta). En cambio, escribiría lo siguiente, que en realidad es más corto en términos de caracteres.

int s = foo(); 
if(s == ERROR) 
    print_error(); 

Ésta no es la primera vez que he visto este idioma, sin embargo, y supongo que hay razones históricas (tal vez) para que sea tan frecuente. ¿Cuáles son esas razones?

Answer 1

Cuando está escribiendo un bucle, a veces es conveniente utilizar la primera forma, como en este ejemplo famoso de K & R:

int c; 

while ((c = getchar()) != EOF) { 
    /* stuff */ 
} 

No hay elegante "segunda forma" manera de escribir esto sin una repetición:

int c = getchar(); 

while (c != EOF) { 
    /* stuff */ 
    c = getchar(); 
} 

O:

int c; 

for (c = getchar(); c != EOF; c = getchar()) { 
    /* stuff */ 
} 

Ahora que t La asignación a c se repite, el código es más propenso a errores, porque uno tiene que mantener ambas declaraciones sincronizadas.

Así que uno tiene que ser capaz de aprender a leer y escribir el primer formulario fácilmente. Y dado que, parece lógico usar la misma forma en las condiciones if también.

Tiendo a utilizar el primer formulario principalmente porque me resulta fácil de leer — como dijo otra persona, une la llamada de función y la prueba de valor de retorno mucho más de cerca.

Answer 2

Creo que es por razones histéricas, que los primeros compiladores no fueron tan inteligentes en la optimización. Al ponerlo en una línea como una sola expresión, le da al compilador una pista de que se puede probar el mismo valor obtenido de foo() en lugar de cargar el valor específicamente desde s.

Prefiero la claridad de su segundo ejemplo, con la tarea y la prueba hechas más tarde. Un compilador moderno no tendrá problemas para optimizar esto en los registros, evitando cargas innecesarias desde el almacén de memoria.

Answer 3

Hago un intento consciente de combinar los dos siempre que sea posible. La "penalización" de tamaño no es suficiente para superar la ventaja en claridad, IMO.

La ventaja de la claridad proviene de un hecho: para una función como esta, siempre se debe pensar en llamar a la función y comprobar el valor devuelto como un solo acción que no puede ser dividida en dos partes ("atómica", Si tu quieres). Debe llamar al nunca, tal función sin probar inmediatamente su valor de retorno.

Separación de los dos (en absoluto) conduce a una mayor probabilidad de que a veces se saltee la comprobación del valor de retorno por completo. Otras veces, accidentalmente inserta un código entre la llamada y la prueba del valor de retorno que realmente depende de que la función haya tenido éxito. Si siempre combinas todo en una sola declaración, (casi) elimina cualquier posibilidad de caer en estas trampas.

Answer 4

A menudo prefiero el primer formulario. No podría decir exactamente por qué, pero tiene algo que ver con la semántica involucrada.

El segundo estilo me parece más como dos operaciones separadas. Llame a la función y luego haga algo con el resultado, 2 cosas diferentes. En el primer estilo, es una unidad lógica. Llame a la función, guarde el resultado temporal y eventualmente maneje el caso de error.

Sé que es bastante vago y está lejos de ser completamente racional, así que usaré uno u otro dependiendo de la importancia de la variable guardada o el caso de prueba.

Answer 5

Siempre iría por el segundo. Es más fácil de leer, no hay peligro de omitir los paréntesis alrededor de la tarea y es más fácil avanzar con un depurador.

Answer 6

A menudo encuentro la separación de la asignación en una línea diferente hace que el reloj del depurador o las ventanas "locales" se comporten mejor frente a la presencia y el valor correcto de "s", al menos en compilaciones no optimizadas.

También permite el uso de step-over por separado en las líneas de asignación y prueba (nuevamente, en compilaciones no optimizadas), lo que puede ser útil si no quiere ir a desordenar en el desmontaje o en la vista mixta.

YMMV por compilador y depurador y para compilaciones optimizadas, por supuesto.

Answer 7

Personalmente prefiero que las asignaciones y las pruebas sean en líneas diferentes. Es menos sintácticamente complicado, menos propenso a errores y más fácil de entender. También permite que el compilador le proporcione ubicaciones de error/advertencia más precisas y, a menudo, facilita la depuración.

También me permite hacer más fácilmente cosas como:

int rc = function(); 

DEBUG_PRINT(rc); 

if (rc == ERROR) { 
    recover_from_error(); 
} else { 
    keep_on_going(rc); 
} 

prefiero este estilo tanto que en el caso de bucles yo más bien:

while (1) { 
    int rc = function(); 
    if (rc == ERROR) { 
     break; 
    } 
    keep_on_going(rc); 
} 

de hacer la tarea en el while condicional. Realmente no me gusta que mis pruebas tengan efectos secundarios.

Answer 8

Creo que la claridad siempre debe primar sobre las optimizaciones o "simplificaciones" basadas únicamente en la cantidad de caracteres escritos. Esta creencia me ha impedido cometer muchos errores tontos.

Separar la asignación y la comparación hace que ambos sean más claros y menos propensos a errores, incluso si la duplicación de la comparación puede introducir un error de vez en cuando. Entre otras cosas, los paréntesis se vuelven rápidamente difíciles de distinguir y mantener todo en una línea introduce más paréntesis. Además, al dividirlo, se limitan las declaraciones a hacer solo una, ya sea de obtener un valor o asignar uno.

Sin embargo, si espera que las personas que lean su código se sientan más cómodas con el idioma de una línea, entonces es lo suficientemente amplio como para no causar ningún problema a la mayoría de los programadores.Los programadores de C sin duda lo sabrán, incluso aquellos que puedan encontrarlo incómodo.