🚀 go-pugleaf

No estoy de acuerdo contigo.

En primer lugar, si tienes un bucle del que desconoces el numero de
iteraciones no se deberia usar un for, sino un while, de modo que dado un
error esto se podria comprobar en la condicion de iteracion.

Despues comentas que lo estamos usando sin saberlo. No creo que poner
returns en medio de funciones sea una buena practica, pero hay veces que eso
simplifica el codigo, sobre todo en funciones en las que chequeas unas
condiciones sin las que la funcion no puede ejecutarse, como por ejemplo los
prerrequisitos de la funcion. En ese caso puedes quitar un monton de ifs,
aunque a mi me sigue gustando mas que solo haya un return al final de la
funcion. Ya he comentado lo de los breaks. Y vuelvo a estar en desacuerdo en
lo de las excepciones y los shifts: evidentemente la construccion de bajo
nivel de las instrucciones incluye saltos incondicionales, pero no estamos
hablando de eso. Estamos hablando de una practica de programacion de alto
nivel que contribuya a una mayor legibilidad de los programas. Precisamente
esas construcciones surgieron para ocultar esos detalles que hacen el codigo
menos legible.

Para terminar dire que puede que yo sea demasiado pesado con esos aspectos
(depende tambien de que este programando), pero en general prefiero un
programa bien estructurado a uno un poco menos lioso.

Gracias por leerme
"Pepito" <kit1972@hotmail.com> escribi� en el mensaje
news:8utqmr$4kd$1@diana.bcn.ttd.net...
> Hola a todos,
>
> Voy a romper una lanza en favor del goto.
>
> En primer lugar debo decir que soy programador profesional de C/C++ desde
> hace 8 a�os y en la facultad nos ense�aron a NO utilizar el goto JAM�S.
> Estuve muchos a�os sin utilizar esa instrucci�n, pero recientemente he
> llegado a la conclusi�n de que en ciertos casos puede ayudar a simplificar
> el c�digo y hacerlo mas legible, adem�s por supuesto que se puede
optimizar
> mucho mas el c�digo y optimizar ciertos algoritmos.
>
> Pongamos un ejemplo:
>
> int funcion ()
> {
>  ...
>  x= new X
>  for () {
>   for () {
>    ...
>    if () {
>     // Se produce un error, �que hacemos?, hay tres opciones:
>     // opci�n 1) return -1 (error no se hace el delete)
>     // opci�n 2) break (debemos guardar un valor de control en una
variable
> para salir luego del bucle externo)
>     // opci�n 3) goto fin: (soluci�n limpia y r�pida)
>    }
>   }
>  }
>
> fin:
>  delete x;
>  ...
> }
>
> De todos modos nosotros cuando programamos estamos utilizando sin saberlo
el
> goto de forma intensiva:
> - Al hacer un return en el medio de una funci�n.
> - Instrucciones del tipo break y continue (en for y while).
> - Manejo de excepciones.
> - Instrucci�n case.
>
> Por lo tanto la conclusi�n es que no es ni blanco ni negro. Ya que tenemos
> una instrucci�n (goto) para modificar el flujo del programa hay que
intentar
> aprovecharla cuando nos sea beneficioso y por supuesto haga mas legible y
> r�pido el c�digo.
>
> Saludos.
>
>
>
>