Para aquellos que les llame la atencion la Programacion

[Reaper45]

(12-10-2013, 09:26 PM)chachibukai escribió:

(12-10-2013, 07:11 PM)Reaper45 escribió:

(12-10-2013, 06:43 PM)chachibukai escribió: Y esa misma condición del if() podría ser prácticamente la misma que la del bucle pero ligeramente modificada. Y está claro que, de haberla metido directamente como condición del bucle, en vez de en un if dentro del propio bucle, habría sido más legible.

Y así estás liándolo de huevos cuando te aparezca una nueva condición de salida. No siempre se te presenta la oportunidad de analizarlo todo previamente.

Hombre, ya digo que hablo en general, sé que hay demasiados factores como para poder elegir una solución perfecta, aplicable en todos los casos, aparte de que me baso en la experiencia, ni siquiera había caído en lo que has dicho porque nunca me ha tocado nada en lo que no pudiera expresar la condición de continuación en el while() desde el primer momento.

Me refiero a nuevos requerimientos en el programa. No estás pensando en la sostenibilidad.

(12-10-2013, 09:26 PM)chachibukai escribió:

Código:

int codigoProducto=6;
int i = 0;
while(i<=tamañoArray && array[i] != codigoProducto) {
    i++
}
if (array[i] == codigoProducto) {
    return(i);
}

Qué atrocidad. Muere, pero antes déjame que te escupa.

[Nosfer]

Lo de los return en bucles o las condiciones de escape dentro de un for no es que no se puedan poner, es que no están bien considerados. Es como conducir por la izquierda cuando tienes el carril derecho libre.
Los bucles for son para recorrerlos de principio a fin, sin condiciones de escape ni modificaciones del contador. Los bucles while son los que se deberían usar si quieres libertad en cuanto a las iteraciones del bucle.

Al final todo se reduce a una estandarización y legibilidad del código. Luego cada cual que programe como le dé la gana, pero a mí me sale la cara de infinito desprecio si veo un return en un bucle o una condición de escape en un for.

[Yumichan]

Pues salvo que tengas potestad para imponer esa estandarización a tu equipo, te tragarás el desprecio y lo rumiarás en soledad.

[LoKo]

Si es por estética de código, dentro de unos limites me da igual.
Ahora bien, si hay alguna razón por la que un return en un bucle priva al compilador de realizar alguna optimización (que es el problema que tiene el primer bucle for que puse en la primera pagina), puedes tener claro que elimino return de dentro el bucle aunque tenga que ir a un código menos elegante como el que ha puesto chachi arriba.

[Nosfer]

(12-11-2013, 09:38 AM)Yumichan escribió: Pues salvo que tengas potestad para imponer esa estandarización a tu equipo, te tragarás el desprecio y lo rumiarás en soledad.

Nunca he impuesto ningún tipo de estandarización a nadie, normalmente llegamos a acuerdos conjuntos sobre cosas más o menos básicas al comenzar el proyecto, aunque se nos van olvidando por el camino y llega un momento en el que no cuesta mucho saber quién ha escrito qué.

Esa estandarización que comento no me la he sacado de la manga, forma parte de la guía (si es que existe alguna guía que recoja este tipo de reglas no escritas) del buen programador. El caso es que es algo que suelen enseñar y algo con lo que he coincidido con casi todos los programadores con los que he trabajado.

[Yumichan]

Imponer por autoridad o argumentos, lo mismo da (o según que puesto te toque).
El caso es de haber estandar se acuerda en el equipo (¿como habeis hecho?), mas que llorar en foros o blogs, "Mira el mierdecilla éste que fors me hace".
Yo, con todos los respetos, por lo de pasar for a while para condiciones de salida te hubiera mandado a la m en una daily y hubiera pasado al siguiente tema.

[Nosfer]

Nunca le he dicho a nadie que cambie nada de un código escrito (salvo que estuviese dando errores XD), ni me he quejado de la forma de programar de nadie. Otra cosa es que no me guste leer ese tipo de cosas, para mí es como leer un texto en mayúsculas o con faltas ortográficas, pero tampoco le digo a la gente cómo tiene que escribir.

Total, al final todo programador aprende a base de tortazos cuando le toca mantener o mejorar un código que hace extraños con el flujo de datos.