[C con Clase] El uso del GOTO.

Salvador Pozo salvador en conclase.net
Dom Nov 16 12:35:07 CET 2008


Hola:

No quería entrar en este hilo porque en el fondo se ah convertido en una cuestión de opinión, y no parece que existan razones que puedan convencer a todos.

(Como se suele decir, la opinión es como el culo (con perdón): cada uno tiene el suyo.)

Se ha apelado a opiniones personales, de profesionales, de teóricos, a usos y costumbres, a tradiciones... nada parece concluyente.

Desde mi punto de vista, el uso del goto se debe evitar si se aplican paradigmas como el de la programación estructurada o la programación orientada a objetos. Estos paradigmas no incluen saltos incondicionales como forma de resolver o modelar problemas, por lo tanto, no son necesarios en ningún caso.

Personalmente, considero que es desaconsejable durante el aprendizaje de la programación, porque (y esto es cierto con demasiada frecuencia), provoca malos hábitos de programación, y todos sabemos que las costumbres que se adquieren cuando se aprende son muy difíciles de corregir. Por eso comprendo que los profesores prohiban su uso de forma radical.

En cuanto a por qué C y C++ incluyen estas sentencias si no son necesarias en la programación estructurada y en POO, la respuesta es simple: C y C++ son lenguajes de propósito general, y por lo tanto, no limitan a los programadores en cuanto al paradigma a usar. El programador es, en última instancia, el responsable de elegir el método que considere mejor para solucionar un problema.

Considero peligroso el razonamiento de que, ya que existe, por qué no usarlo si nos ahorra trabajo, o si nos proporciona atajos o soluciones "mágicas", a problemas concretos. Empezaremos por dejarnos tentar "bueno, sólo por esta vez", y acabará por parecernos una solución natural.

Los paradigmas fueron creados por varios motivos. El primero es para sistematizar la resolución de problemas, en lugar de dejar todo a la intuición e inspiración del programador. La programación, gracias a eso, se acerca más a una técnica y se aleja del "arte". Esto es bueno, porque es más fácil enseñar y aprender una técnica. Practicar un arte requiere condiciones innatas, la programación (al menos a cierto nivel), no tantas. También es bueno porque permite una evolución, avance o investigación, algo más difícil si se trata de un arte.

Otro motivo, no menos importante, es que distintos programadores puedan comprender programas escritos por otros programadores, puesto que todos aplicamos las mismas reglas, al analizar programas (propios o ajenos), podremos deducir mejor el funcionamiento, y si es necesario, corregirlos o actualizarlos.

Por eso un "goto" en un programa descoloca tanto a un programador que lo analiza, porque no encuentra ninguna regla que justifique su uso.

¿Hay casos en que es admisible el uso de goto?

Claro, para eso permanece en el lenguaje. Recordemos que C y C++ permiten programación a bajo nivel (o al menos bastante bajo). Una rutina destinada a trabajo en tiempo real, o a manipular dispositivos de entrada y salida, requiere tal grado de optimización que podríamos decir que todo vale. Pero en esos casos sería muy importante añadir documentación extra, en forma de comentarios, sobre lo que hace el código. Es más, si el código en cuestión procede de uno anterior optimizado, sería bueno dejar el original como comentario, ya que ayudaría a otros programadores, y a nosotros mismos, a comprender el funcionamiento.

Al contrario de lo que sucede con otras disciplinas, como la mecánica o la electricidad, en informática no se suele abundar en el análisis de programas. En otras disciplinas, se dedica mucho tiempo al análisis antes de pasar al diseño. En programación prácticamente no se analiza nada, y se pasa directamente al diseño. Creo que esto es un error, y que nos iría mejor si dedicáramos más tiempo a intentar comprender lo que escriben otros.

A nadie se le ocurre empezar a escribir una novela sin haber leído antes varios cientos de ellas. Sin embargo, muchos programadores se lanzan a escribir aplicaciones sin haber analizado nunca más de unas líneas de código.

En este sentido, el goto no es más que la punta del iceberg. Hay un montón de reglas (reglas de estilo), que tendríamos que conocer y aplicar para uniformar el código tanto como sea posible: tabulaciones, cuando usar do...while, tamaño de las funciones, estructura de programas y proyectos, anidamientos máximos, etc.

Por último, añadir que en mis programas (no voy a decir cuánto tiempo llevo programando), no he usado un goto desde que dejé de programar en BASIC. Y aunque en ese lenguaje era imprescindible, ya que la única estructura de control era el FOR, yo no lo usaba por eso, sino porque programaba de forma intuitiva.

Ahora no los uso porque no hacen falta, y cuando estoy en un atoyadero, ni siquiera lo considero entre mis opciones. Esto es por costumbre, por supuesto, pero creo que es una buena costumbre.

Por supuesto, a fin de cuentas, estas también son mis "opiniones"...

P.D.: Por mi parte, doy el tema por cerrado (al menos en lo que respecta a opiniones). Por favor, seamos un poco "científicos", y razonemos nuestros puntos de vista.

-- 
Salvador Pozo (Administrador)
mailto:salvador en conclase.net


Más información sobre la lista de distribución Cconclase