Barrapunto

Reenvío y perdona, que los menorque no le gustan al parser de barrapunto.

> Sigo pensando que es preferible programar como digo

Obviamente, es preferible poner la condición .

El problema al que hacía referencia es que en código de bajo nivel o mínimamente complejo, casi nunca tienes el canónico y venerado bucle "for (int i = 0; i menorque n; ++i)" o "while (i menorque n)".

Cuando escribas código para microcontroladores, para un kernel o para algoritmos matemáticos complejos ya te darás cuenta, joven.

> Y por el otro lado, sigo pensando que while(1) es más legible

A mí me da igual ver/escribir while(1) o for(;;). Si eres ingeniero deberías estar acostumbrado a leer cosas iguales con mil notaciones diferentes y no cabrearte por ello.

> Pero a lo mejor ya es manía personal porque en el único código que me ha tocado tocar con for(;;) era una chapuza de código (encima pro*c), tal vez el más guarrero y más difícil de seguir que he visto nunca.

Seguramente, porque si has estudiado estadística, sabrás que una única observación de una muestra no concluye absolutamente nada.

Barrapunto es un poco puñetero con los símbolos < y > porque cree que estás tratando de meter etiquetas HTML. La forma es escribir &lt; y &gt;, o si estás escribiendo código lo mejor visualmente y más cómodo es rodear el bloque con <ecode> y </ecode>.

casi nunca tienes el canónico y venerado bucle "for (int i = 0; i menorque n; ++i)" o "while (i menorque n)".

Las condiciones pueden ser más complejas que i<n, pero a ser posible deberían intentar expresarse. Yo tampoco hago todos los bucles canónicos, pero si procuro que sean for ( inicialización ; condición ; avance ).

Por ejemplo, para una estructura de datos imaginaria:

for ( p=l->first ; p && !p->exit ; p = p->next)

Y en los casos en que esa condición no se encuentre fácilmente, o suponga una sobrecarga significativa, y haya que recurrir a break, hay que hacerlo con sumo cuidado para evitar errores, efectos laterales y cambios del flujo del programa que puedan pasar desapercibidos a quien coja ese código después.

Cuando escribas código para microcontroladores, para un kernel [...], joven.

No he hecho eso ni tengo previsto hacerlo (aunque con los tumbos que me dan no es descartable), pero estamos hablando de programación C, no necesariamente programación de microprocesadores.

sabrás que una única observación de una muestra no concluye absolutamente nada

Lo sé, claro, y por eso mi comentario era una concesión de que tal vez hubiera algo de tirria personal por mi parte.