Para aquellos que les llame la atencion la Programacion

[Chachibukai]

(12-10-2013, 02:21 PM)xoker escribió: Cuando yo programo en ensamblador MIPS, ARM o x86 lo que yo hago es usar etiquetas y hacer saltos condiciones o incondicionales a estas segun el caso, nunca he usado un GOTO en ensamblador ni lo he visto si quiera...

Si te refieres a lo que he comentado antes, me refería a que el goto lo veíamos en C como el equivalente del jmp en ensamblador. Luego ya comenzamos a ver los condicionales y los bucles en C como combinaciones en ensamblador de cmpl con je, jne, etc.

[xoker]

(12-10-2013, 02:51 PM)Nosfer escribió: Un return en un bucle dentro de una función es un ejemplo de lugar inapropiado.

Claro claro, en un bucle yo utilizo una ruta de escape cuando se da segun que situacion y ya realizo el return al final de la funcion, pero por ejemplo alguna que otra vez si que he hecho un return en un condicional, del tipo de if(...) return x; else return y; Eso si he cuidado mucho donde hacerlo

Por cierto, que habeis estudiado de informatica?? Como ya he dicho, yo me encuentro realizando el Grado en Ingenieria Informatica en la Universidad de Cadiz (España)

[LoKo]

(12-10-2013, 02:51 PM)Nosfer escribió: Un return en un bucle dentro de una función es un ejemplo de lugar inapropiado.

¿Me puedes/podéis dar una explicación técnica de porque es inapropiado?
He visto algunos programas que lo tienen y si no recuerdo mal, en compiladores cuando nos explicaban el porque de no usar goto nos decían que el return era otra historia porque si que estaba controlado donde saltaban, cosa que el goto, pues como que no.

[Chachibukai]

(12-10-2013, 05:10 PM)LoKo escribió:

(12-10-2013, 02:51 PM)Nosfer escribió: Un return en un bucle dentro de una función es un ejemplo de lugar inapropiado.

¿Me puedes/podéis dar una explicación técnica de porque es inapropiado?
He visto algunos programas que lo tienen y si no recuerdo mal, en compiladores cuando nos explicaban el porque de no usar goto nos decían que el return era otra historia porque si que estaba controlado donde saltaban, cosa que el goto, pues como que no.

Supongo que será porque no poner el return() dentro del bucle te obliga a poner una condición de continuación para el bucle correcta, lo que por lo general simplificaría la comprensión. Porque si no, como con el goto, igual empezaría a llenarse de apaños y burradas estilo "hago un while(1) y cuando quiera salir del bucle ya le meteré un break() o un return(). Pero para eso, tengo que meter un if() dentro del bucle.".

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.

Es lo que comentaba antes de la importancia de aprender a derivar y tal antes de comenzar a programar a lo burro. En su día me acabé morado con los invariantes en bucles.

[xoker]

(12-10-2013, 06:43 PM)chachibukai escribió: En su día me acabé morado con los invariantes en bucles.

Calla calla, no nombres al diablo que tengo despues de navidad el examen de esa asignatura y me trae amargado... no es por que no sepa encontrar invariantes y tal, sino porque esta es de las tipicas asignaturas en que como cometas un error tonto estas suspendido... se saca o todo o nada

[Reaper45]

A mí me gusta bastante más un break dentro de un for si con ello evito, por ejemplo, hacer un

Código:

for(int i = 0;i < 10 && checkCondition();i++) {
  doStuff();
}

o los estupentásticos

Código:

for(int i = 0;i < 10 && doStuff();i++);

Punto y coma, eah. Realmente la legibilidad es cosa de sentido común.

Tampoco puede ser necesario hacer cada iteración completa.

(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.

(12-10-2013, 10:47 AM)Nosfer escribió: PD: Nunca me fio de los programadores que dicen que dominan un lenguaje de programación

Nunca me fío de los programadores que dicen que no meten la gamba. Son tan raros como los billetes de 1000 euros.

[LoKo]

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

Código:

for(int i = 0;i < 10 && doStuff();i++);

Te odio.
Solo por presentarme semejante código sangrante. Entra al portal y tírate un par de veces por algún acantilado, date algún baño y quítate puentes de luz.

---

(12-10-2013, 06:43 PM)chachibukai escribió: Supongo que será porque no poner el return() dentro del bucle te obliga a poner una condición de continuación para el bucle correcta, lo que por lo general simplificaría la comprensión. Porque si no, como con el goto, igual empezaría a llenarse de apaños y burradas estilo "hago un while(1) y cuando quiera salir del bucle ya le meteré un break() o un return(). Pero para eso, tengo que meter un if() dentro del bucle.".

Hombre, a mi no me parece mal que un código que busca algo dentro de un array haga algo del estilo

Código:

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

El tema de no usar while ha sido por comodidad.

[Chachibukai]

(12-10-2013, 07:11 PM)Reaper45 escribió: A mí me gusta bastante más un break dentro de un for si con ello evito, por ejemplo, hacer un

Código:

for(int i = 0;i < 10 && checkCondition();i++) {
  doStuff();
}

Yo me refería más a los while. Los for prefiero usarlos precisamente para cuando ya tengo controlado cuándo va a acabar el bucle, y no necesito hacer comprobaciones extra. Pero si tuviera que hacerlas, posiblemente sí preferiría dejar los parámetros del for lo más simples posible, metiendo sólo cosas relevantes a la i, (int i=0;i<10;i++), y meter las condiciones adicionales dentro.

(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.

---

(12-10-2013, 07:38 PM)LoKo escribió: Hombre, a mi no me parece mal que un código que busca algo dentro de un array haga algo del estilo

Código:

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

A mí es que ya digo que desde el principio me inculcaron la derivación formal y una serie de reglas que reconozco que en ocasiones pueden ser un coñazo (en cuyo caso no las uso, pero no puedo evitar sentirme algo incómodo, como cuando estás en java nombrando las cosas estilo estoEsUnaCosa y es un trabajo por parejas y el otro llama a las cosas esto_es_otra_cosa y te dan ganas de toquetear todo su código (intuyo que Reaper me comprenderá )), así que mi impulso inicial sería hacer el código de LoKo como:

Código:

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

Que es lo que decía al principio: como no sé cuándo va a acabar el bucle, me tienta ponerlo como while, porque me acostumbraron así, pero entonces me queda una cosa muy fea que me podría haber evitado con un for.

[Yumichan]

Prefiero el bucle de Loko

[Chachibukai]

No, si yo también, por eso he dicho que me tienta XD
Sé reconocer cuándo las cosas son manías mías que no merecen la pena.