🚀 go-pugleaf

Cuando empec� a programar en cobol por los a�os 80 mi profesor ya me
prohib�a terminantemente la utilizaci�n del dichoso GOTO, as� que a estas
alturas me parece su uso no puede decir nada muy profesional del programador
que lo usa.

Saludos. :)

On Tue, 14 Nov 2000 21:15:11 GMT, "Miguel A. Fuentes"
<tatoflis@wanadoo.es> wrote:

Seg�n la teor�a de programaci�n estructurada se puede evitar siempre,
en la realidad... yo a las excepciones las veo casi como un goto, que
quereis que os diga.

Hola Miguel

Desde hace tiempo se considera el uso del 'goto' (ruptura incondicional del
flujo normal) como inadecuado en la programaci�n de alto nivel. Esto es as�
porque tiende a hacer los programas ilegibles, constituyendo lo que se llama
'c�digo spaghetti', y porque impide determinadas optimizaciones del
compilador.

Te�ricamente, cualquier estructura de control de flujo, bien de iteraci�n
(for, while, do-while), bien de selecci�n (if, switch), puede suplir el uso
de cualquier goto.

No obstante, algunos autores (entre los que se encuentra Herbert Schildt)
consideran que el uso del 'goto' puede ser incluso beneficioso en
determinadas circunstancias, como por ejemplo la salida de un conjunto de
bucles anidados. Sin embargo, este autor es partidario no de la utilizaci�n
del 'goto' a pelo, sino de su forma m�s civilizada: 'break'.

Tengo que decir que no estoy de acuerdo con esto, y que cualquier salida de
un bucle deber�a ser evaluada en la condici�n de permanencia en el mismo.

Hubo un tiempo en que pensaba que la incorrecci�n del uso del 'goto'
descend�a a medida que lo hac�a el nivel del lenguaje de programaci�n
utilizado. Es decir, la utilizaci�n de una sentencia
'goto' en un programa escrito en un lenguaje de alto nivel deb�a
considerarse un pecado mortal, pero su uso en un programa escrito en
ensamblador ('jmp') era un pecadillo, y m�s a�n, incluso era necesario. Pero
esto s�lo hasta que descubr� la riqueza de instrucciones de salto
condicionales que exist�an en los ensambladores de distintas arquitecturas.

Desde ese entonces no he vuelto a utilizar un 'jmp' jam�s.

Salud

David

"Miguel A. Fuentes" <tatoflis@wanadoo.es> escribi� en el mensaje
news:zXhQ5.698$cQ5.16259@m2newsread.uni2.es...
> Bueno, este mensaje es para sacar conclusiones con la orden GOTO en los
> lenguajes de alto nivel.
> Un grupo de alumnos de la Universidad y un Tutor discur�a al decir que la
> sentencia GOTO, tarde o temprano "la tendr�s que utilizar". Si el programa
> se complica tendras que utilizar la famosita orden, pero.... Que pasa con
la
> programaci�n estructurada?�Que pasa con las modificaciones del programa en
> un futuro?�Que pasa con el jefe del departamento de programaci�n que ve
ese
> programa hecho de esa manera?.
> Bueno, fue una discusi�n en la que el propio tutor afirmaba que la orden
> GOTO la utilizaras tarde o temprano.
> Como es de imaginar, el aqu� presente era la persona encarada en esa
> discusi�n (no llegamos a las manos :-P) con el tutor y algunos alumnos
> asistentes a la tutoria.
> Personalmente, aportaba que esa orden est� en deshuso, si bien algunos
> lenguajes, digamos que nuevos, ya no la incorporan �Por que sera?,�Es
> posible que la programacion estructurada no sea capaz de resolver un
> problema sin que se tenga que utilizar el GOTO?
> Desde hace mucho tiempo estoy programando y he visto multitud de
> aplicaciones, grandes y peque�as, y JAM�S he visto un GOTO, casualidad?
> Es sabido que esa orden no figura en ningun manual del buen programador,
> pero dejo la pregunta a la lista para que, aclarar o no, dejen su opini�n
> sobre la instrucci�n GOTO y la programaci�n de hoy en dia en lenguajes de
> alto nivel.
> En cualquier caso, agradecer�a un comentario sobre las cuestiones aki
> expuestas.
> Un saludo a todos.

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.

Totalmente de acuerdo!!!!!

�Pedazo de lanza!
Es muy buena tu contestaci�n.

Saludos. :)

"Miguel A. Fuentes" escribió:

> Desde hace mucho tiempo estoy programando y he visto multitud de
> aplicaciones, grandes y pequeñas, y JAMÁS he visto un GOTO, casualidad?

    Prueba con esto y verás...

        cat /usr/src/linux/kernel/sched.c  |  grep "goto"

    Yo sí lo he visto en otros sitios... OpenSSL por ejemplo...

    Bueno, nada... un saludo...

Llevo 10 a�os programando y jam�s he utilizado el GOTO. S� lo he visto en
programas COBOL viejos, hechos por gente "viciada", pero la mayor�a en casos
puntuales como "GOTO ERROR".

En mi opini�n lo �nico que hace es confundir. Adem�s si se utiliza cualquier
metodolog�a es imposible que te salga un GOTO.

Por cierto (y sin animo de crear polemica) conozco a una chica que programa
en Access y VisualBasic que NO ha estudiado la carrera de informatica, sino
un modulo de FP. Pues esta chica NO usaba el WHILE, lo hac�a todo con IF y
GOTO. Os podeis imaginar lo chungo que era entender un programa suyo...menos
mal (para ella) que le guiamos por el buen camino.

Suerte.Z.

In article <8utqmr$4kd$1@diana.bcn.ttd.net>, Pepito wrote:
> 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.
>
si a eso le llamas goto  te has dejado cuando llamas a una funcion (subrutina o 
procedimiento) al realizar un if en cualquier bucle o interacion o extructura 
de control...

On Wed, 15 Nov 2000 22:10:11 GMT, mallok <jsegam@terra.es> wrote:

>"Miguel A. Fuentes" escribi�:
>
>> Desde hace mucho tiempo estoy programando y he visto multitud de
>> aplicaciones, grandes y peque�as, y JAM�S he visto un GOTO, casualidad?
>
>    Prueba con esto y ver�s...
>
>        cat /usr/src/linux/kernel/sched.c  |  grep "goto"
>
>    Yo s� lo he visto en otros sitios... OpenSSL por ejemplo...

Je, je, Linux no debe de ser desde luego el paradigma de la
programaci�n estructurada (aunque si eficiente). No se donde he leido
que el c�digo de Linux se parece bastante a la programaci�n orientada
a objetos por el hecho de usar mucho los apuntadores a funciones para
hacer algo parecido al polimorfismoy noseque historias mas, o sea, que
no es muy ortodoxo que digamos.

On Thu, 16 Nov 2000 09:05:49 +0100, Jos� Luis P�rez Diez
<Jluis@noEmai.com> wrote:

>In article <8utqmr$4kd$1@diana.bcn.ttd.net>, Pepito wrote:
>> 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.
>>
>si a eso le llamas goto  te has dejado cuando llamas a una funcion (subrutina o 
>procedimiento) al realizar un if en cualquier bucle o interacion o extructura 
>de control...

No, no es lo mismo, cuando llamas a una funcion saltas a otro punto
del programa, pero al terminar vuelves a ese punto, no cruzas lineas.
Sin embargo en las excepciones saltas a otro punto del programa y
generalmente no vuelves, una excepci�n NUNCA puede encajar en un
entorno de programaci�n extructurade PURO, no al menos en el contexto
en el que se formul� la teor�a de la programaci�n estructurada. Yo que
quereis que os diga, las excepciones las veo como un GOTO refinado,
una manera de hacer un GOTO sin que quede tan feo, eso si, est�
cojonudas y son mucho mas faciles de entender que un GOTO, de hecho es
mas facil de entender un m�todo que lanza excepciones que un m�todo
que continuamente est� chequeando "a mano" que no se producen.

On Thu, 16 Nov 2000 14:38:43 GMT, Pumuki wrote:

No es lo mismo excepto cuando en Cobol por ejemplo haces una llamada
al Perform Final...

>On Thu, 16 Nov 2000 09:05:49 +0100, Jos� Luis P�rez Diez
><Jluis@noEmai.com> wrote:
>
>>In article <8utqmr$4kd$1@diana.bcn.ttd.net>, Pepito wrote:
>>> 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.
>>>
>>si a eso le llamas goto  te has dejado cuando llamas a una funcion (subrutina o 
>>procedimiento) al realizar un if en cualquier bucle o interacion o extructura 
>>de control...
>
>No, no es lo mismo, cuando llamas a una funcion saltas a otro punto
>del programa, pero al terminar vuelves a ese punto, no cruzas lineas.
>Sin embargo en las excepciones saltas a otro punto del programa y
>generalmente no vuelves, una excepci�n NUNCA puede encajar en un
>entorno de programaci�n extructurade PURO, no al menos en el contexto
>en el que se formul� la teor�a de la programaci�n estructurada. Yo que
>quereis que os diga, las excepciones las veo como un GOTO refinado,
>una manera de hacer un GOTO sin que quede tan feo, eso si, est�
>cojonudas y son mucho mas faciles de entender que un GOTO, de hecho es
>mas facil de entender un m�todo que lanza excepciones que un m�todo
>que continuamente est� chequeando "a mano" que no se producen.

On Thu, 16 Nov 2000 14:52:46 GMT, pumuki@falsa.es (Pumuki) wrote:

>On Thu, 16 Nov 2000 14:38:43 GMT, Pumuki wrote:

>No es lo mismo excepto cuando en Cobol por ejemplo haces una llamada
>al Perform Final...

Bueno, COBOL es otro mundo, COBOL es por definicion el lenguaje
orientado a la programaci�n desestructurada.

Pepito wrote:

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

Has hecho algo de trampa, tocayo :-). En Java (dir�a que en C++ tambi�n, pero
hace tiempo que no le pongo las zarpas encima) existe algo llamado throw para
gestionar errores

Luego, sobre lo que comentas de gotos "invisibles". No es lo mismo. El goto es
una transferencia totalmente incondicional y a un lugar no especificado a
priori. Eso lo convierte en algo muy parecido a una escopeta cargada y de
gatillo muy sensible.

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

Para ser honrados, el mism�simo Wirth postulaba a�os ha que en algunos casos el
goto era la mejor soluci�n. Sin embargo, con los recursos que ofrecen los
lenguajes de alto nivel hoy en d�a, el goto me parece totalmente innecesario, ni
para hacer m�s legible el c�digo ni para optimizar su velocidad (cuidado con las
optimizaciones "a mano de c�digo fuente, que a menudo resultan ser
"pesimizaciones")

Un saludo

Pep
.

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

In article <brl71tohh1ic0kk2sq5inv8uumskt24jdp@4ax.com>, DrPanic wrote:
> No, no es lo mismo, cuando llamas a una funcion saltas a otro punto
> del programa, pero al terminar vuelves a ese punto, no cruzas lineas.

Cuandos llamas a una funcion o procedimiento esperas que retorne (lo cual 
supone dos saltos) pero no siempre es asi

> Sin embargo en las excepciones saltas a otro punto del programa y
> generalmente no vuelves, una excepci�n NUNCA puede encajar en un
> entorno de programaci�n extructurade PURO, no al menos en el contexto
> en el que se formul� la teor�a de la programaci�n estructurada. 

Las escepciones no controladas puede que lo hagan pero si programas el manejo 
de una no tiene porque no volver otra cosa son las estructuras de control tipo 
try /catch

> Yo que quereis que os diga, las excepciones las veo como un GOTO refinado,
> una manera de hacer un GOTO sin que quede tan feo, eso si, est�
> cojonudas y son mucho mas faciles de entender que un GOTO, de hecho es
> mas facil de entender un m�todo que lanza excepciones que un m�todo
> que continuamente est� chequeando "a mano" que no se producen.
>

Pues no se como dividir por cero pueda ser un GOto refinado pero ...;-)

In article <49a61t8epk5iuuqrr6rvpnp6g0ic1d6nkm@4ax.com>, DrPanic wrote:
> Je, je, Linux no debe de ser desde luego el paradigma de la
> programaci�n estructurada (aunque si eficiente). No se donde he leido
> que el c�digo de Linux se parece bastante a la programaci�n orientada
> a objetos por el hecho de usar mucho los apuntadores a funciones para
> hacer algo parecido al polimorfismoy noseque historias mas, o sea, que
> no es muy ortodoxo que digamos.
>
La programacion estructurada es simplemente un subconjunto de la orientada a 
objetos.