Portada
mis comunidades
otras secciones
#6:
En resumen:
Si trabajas para una empresa cárnica de mierda y sabes que te van a poner en la puta calle en cuantos les dé el punto, es decir, al final del proyecto, llena todo de GOTOS, no pongas comentarios y procura llamar a las variables mediante nombres que no tengan absolutamente nada que ver con su uso.
Despues, borra todos los tabs para quitar la indentación.
Luego, si quieren, QUE TE DESPIDAN.
Si trabajas para una empresa cárnica de mierda y sabes que te van a poner en la puta calle en cuantos les dé el punto, es decir, al final del proyecto, llena todo de GOTOS, no pongas comentarios y procura llamar a las variables mediante nombres que no tengan absolutamente nada que ver con su uso.
Despues, borra todos los tabs para quitar la indentación.
Luego, si quieren, QUE TE DESPIDAN.
Comentarios
En resumen:
Si trabajas para una empresa cárnica de mierda y sabes que te van a poner en la puta calle en cuantos les dé el punto, es decir, al final del proyecto, llena todo de GOTOS, no pongas comentarios y procura llamar a las variables mediante nombres que no tengan absolutamente nada que ver con su uso.
Despues, borra todos los tabs para quitar la indentación.
Luego, si quieren, QUE TE DESPIDAN.
El uso de GOTO no debería ser usado en casos en que rompa la programación estructurada. Seguir un código con GOTO's es un caos. Podemos decir, que la programación en COBOL, se usa el GOTO siempre con cierta logica donde haciendo etiquetas te lleve al final de la etiqueta y se pueda seguir el código sin problema. Es decir, es como salir de esa etiqueta (Podemos decir que etiquetas en cobol, pueden ser similares a funciones o procedimientos).En una programación estructurada el uso del GOTO puede ser terrible, y sobre todo el abuso de esta sentencia.
#8 "si usas goto te volverás ciego y te saldrán granos"
pues yo estoy medio ciego y lleno de granos y no uso gotos... ¿de qué puede ser?
Si, si estoy de acuerdo con lo que decís, #4 y #5. Lo que pasa es que también he leído muchas tonterías sobre esto, incluso en la facultad nos explicaron que no había que usarlo porque no permitía establecer condiciones ni estructrar el flujo del programa. Y poderse se puede, otro tema es que sea, como decís, un coñazo
.
Creo que a veces falta sentido crítico, me da rabia ese "si usas goto te volverás ciego y te saldrán granos"
#8 es que si te pones a leer código con muchos gotos, al final te quedas ciego... lo de los ganos todavía hay que contrastarlo
#8 "no permitía establecer condiciones ni estructurar el flujo del programa"
Eso se puede deber a una falta de comprensión de relaciones lógicas por parte de quien lo dijese. En realidad sería:
"sí-permite no-establecer condiciones y no-estructurar el flujo del programa"
Lo cual no-impide, y por tanto sí-permite, sí-meter la pata de innumerables formas
"Dijkstra seems to imply that iterative looping (inductive) statements are intellectually harder to grasp than recursion, which is the kind of thing only a mathematician would say."
Laugh, it's funny
#3 El código que has puesto, si que sigue siendo lo mismo, es decir, a nivel de ejecución de instrucciones es lo mismo, pero no es un "código elegante", por decirlo de alguna manera.
En el caso del primer If, se vee claramente que despues que se cumpla la condición va por otra ramificación que vuelve a la siguiente instrucción.
El el segundo caso, tambien haria lo mismo, pero no se vee bien claro a donde vuelve una vez que termine la etiqueta funcion.
Este segundo caso que has puesto, a mi entender, creo que es el tipico en que no se debe de usar el GOTO.
Esta claro que a bajo nivel el GOTO es más usado, pero date cuenta, que a bajo nivel no tenemos tantas funciones y/o instrucciones que nos permitan hacer más cosas que un lenguaje de alto nivel....
En ensamblador, por ejemplo, tenemos el jmp, etc... Aqui el uso de gotos puede ser más justificados, también.
Es mi opinión.
Tan malo es el uso de GOTO's como el abuso innecesario de llamadas a funciones. Actualmente estoy revisando un código que nos ha pasado otra empresa, y estoy alucinando que para algo tan simple como mostrar un listado de datos, se llamen a unas 15 funciones repartidas entre 7 paginas PHP... Para ver en qué punto se está perdiendo un dato me estoy volviendo loco...
¿Alguien que lo resuma?
La justificación: http://xkcd.com/292/
también hay mucho de dogma en todo esto, quiero decir, qué diferencia hay entre:
if(condicion == 0) ejecutar_funcion();
y
if(condicion == 0) goto funcion;
evaluar: // sigue el código
Si en la etiqueta funcion metemos código y terminamos con un goto evaluar; sigue siendo lo mismo, ¿no? de hecho a bajo nivel las cosas funcionan así
#3 A bajo nivel es así, y realmente una llamada a función equivale a lo que tu nos comentas... El problema surge cuando te toca analizar el código de alguien que por comodidad pone un goto a una etiqueta "vete a saber tu donde"... es muy difícil seguir el flujo del programa... te lo digo por experiencia, que ahora mismo me está tocando a mi revisar un código fuente para encontrar un fallo y me estoy volviendo loco!
#1 Usar GOTOs es malo
Básicamente, define las bases de la programación orientada a objetos, donde no es suficiente con saber "qué" ejecutar, sino que también hay que conocer el estado de los datos asociados al objeto (o estado de la función como dice). Aplicado a todo el código, podemos decir que cada bloque de código (dentro de un it-then(...)else(...), un for(...), un while(...) etc.) presupone un estado para unos datos concretos dentro del bloque, comportándose en efecto como si fuese una función o un mini-objeto. El uso del GOTO es malo dado que permite ejecutar cualquier código "en medio" de una función/objeto, sin exigir que se respeten las asunciones que ese código hace sobre el estado de los datos que manipula.
Un ejemplo simple:
10 function blabla( $a )
50 $a = 0;
60 GOTO 30
Resultado: división entre cero, error y todo a tpc por no haber respetado la comprobación en la línea 20.