Historia de un Viejo Informático. La Programación Estructurada

Nueva entrega de la serie Historia de un Viejo Informatico. En su linea: Hoy le toca a la programacion estructurada.

[#8 Desactivado]

#1 Que moderno!!! Ahora los buenos y malos métodos se distinguen por el numero de líneas.......

[#2 maxim.rudin]

Las entradas anteriores, para el que se las halla perdido:
http://eltamiz.com/elcedazo/2009/02/05/historia-de-un-viejo-informatico-los-estudios-el-instituto-de-informatica/
http://eltamiz.com/elcedazo/2009/02/10/historia-de-un-viejo-informatico-el-equipamiento-informatico-en-la-decada-de-los-setenta/
http://eltamiz.com/elcedazo/2009/02/17/historia-de-un-viejo-informatico-el-metodo-de-trabajo-en-proceso-de-datos-en-la-decada-de-los-setenta/
http://eltamiz.com/elcedazo/2009/02/24/historia-de-un-viejo-informatico-los-mainframes-de-ibm/
http://eltamiz.com/elcedazo/2009/03/02/el-cobol-virus-del-milenio/
http://eltamiz.com/elcedazo/2009/03/09/historia-de-un-viejo-informatico-el-metodo-de-trabajo-en-los-ochenta/

Todos larguisimos y llenos de información...

[#9 fabeirojorge]

En la Facultad de Informática de A Coruña hasta hace un par de añitos nos enseñaban Warnier en una asignatura de segundo llamada Metodología de la Programación (MP para los amigos), así que todo buen informático salido de la FIC se ha tenido que pelear con los ficheros lógicos de entrada, salida, etc. en el examen...

[#16 basti]

#1 La programación estructurada y la OOP no son excluyentes.

[#5 cosmonauta]

Aquí los tenéis todos. (Misma info que #2, pero más fácil de añadir como marcador, creo yo).

http://eltamiz.com/elcedazo/category/Macluskey/

[#1 vicious]

muchos siguen anclados en ella, incluso en proyectos Java... sólo hay que ver métodos con hasta 100 líenas como he llegado a ver yo... y no era el main()

[#27 in0de]

Los que decís que un método con 100 líneas es señal de que hay un problema, no sé con qué tipo de proyectos trabajais, la verdad. Actualmente estoy diseñando y revisando código de mi proyecto (un servicio de registro de servicios y entidades basados en UDDI y DNS) y hay métodos que realmente hacen 4 llamadas (son delegates) a otros servicios y llegan a las 80 líneas. Sobre todo en Java, donde tanto try/catch y declaraciones de nestedObjects se hacen tan largas que no me parece nada fuera de lo normal.

Dejad de decir barbaridades porque 100 líneas no es nada asombroso. Eso sí, un método donde llegas a tener 800 líneas del tirón... ahí sí que puedes estructurarlo en varios objetos o nivelar las capas para poner cada cosa en su sitio.

Y si seguís encabezonados con eso, pues pasaros por googlecode y echadle un ojo a GWT, donde el compilador tiene métodos de más de 300 líneas. Y está hecho por los superduper programadores de jujel !

[#30 hangla]

#29 Lo primero que me dijeron cuando empece la carrera : "El que use un GOTO esta suspenso"... aquellas clases de Pascal....

[#26 Desactivado]

Pues yo 25cm

[#3 maxim.rudin]

Huy, queria decir "haya"...

[#6 quicksort]

Y algunos se quejan de que las carreras de informáticas actuales son demasiado teóricas

[#33 Desactivado]

#17 #24 #25 Eso no es nada. Yo he visto un fichero en C de 33.000 líneas de código bien espeso (poco espacio en blanco o comentarios).

Era un módulo de un simulador de una GPU. El módulo aquel era una pipeline programable con hyperthreading.

Respecto a la longitud de los métodos, los he visto de 2.000 líneas de C. Era un compilador que tuve que mantener.

Cómo me alegro de haber dejado aquella empresa.

[#35 Laurent]

Aparte de que métodos con menor número de líneas sean más legibles que los que tienen un montón de líneas, probad a mantener un método de 500 líneas o, por el contrario, 10 métodos de 50 líneas donde un 11º método general va llamando a los 10 métodos de forma sucesiva.

Obviamente, mientras los métodos realicen funciones bien definidas exentas de ambigüedades, la 2ª opción aporta muchísimas más ventajas que la primera:

- Mayor facilidad para la detección de errores en el código.
- Mayor facilidad para saber qué parte del código se ejecuta más eficientemente (tiempo de CPU y uso de memoria). Ello conlleva que nos centremos más en cierta parte del código para optimizaciones.
- Mayor facilidad para la extensibilidad del código.
- Mayor grado de legibilidad. La legibilidad de un código se puede comprobar de forma muy fácil: coge el código y llévaselo a alguien que no lo haya programado. Cuanto más legible y ordenado, menos tiempo tardará en entender cómo funciona.

Lógicamente, pueden haber métodos de 100 líneas que estén bien definidos. Se pueden manejar sin muchos problemas. Pero cuando empezamos a hablar de 300, 400, 500 líneas, etc, etc, etc... a ver quién es el valiente que mantiene eso.

[#34 equisdx]

¡Ainss! que recuerdos me trae de la asignatura de Cobol.

[#44 mbf]

Que buenos recuerdos me trae todo esto; cuamdo mirabas un programa y solamente viendo donde estaban colocadas las lecturas ya sabias si era bueno o era un truño, ¡que tiempos!. Por cierto con la práctica aprendías a calar la estructura lógica de los datos al momento y sin esfuerzo, con lo que la mayoría de problemas te los pulías en un santiamén. Bueno, saludos del abuelo cebolleta.

[#4 cosmonauta]

Genial. Simplemente genial.

Diría yo, que algún diagrama de esos todavía lo llegué a ver por la universidad.

[#15 VortixTM]

Hay veces que, simplemente, no puedes hacer las cosas de otra manera.

Ya sea por la tecnología con la que trabajas o por la singularidad del método concreto, a veces hacer algo en menos de 'X' lineas no es factible.

Eso de "métodos de pocas líneas" es más bien una pauta general, no una regla que se cumpla invariablemente. Si se divide un método de 100 líneas en 10 métodos de 9 líneas cada uno no tiene por qué mejorarse la eficiencia del código.

Un caso de ejemplo. Tenemos una tabla en la base de datos de "detalles de cliente" que consta de 150 campos. Para recuperar una entrada de esa tabla implementamos un cliente Tuxedo que nos devuelve un registro por su clave primaria. Ese registro, traducido de base de datos a C/C++, se convierte en una estructura que recoge el registro completo de la BBDD. He aquí mi pregunta: ¿cómo vuelcas el cursor de base de datos a la estructura en menos de 150 líneas?

La verdad, si os alucinan tanto esas cosas, me parece que no habéis visto aplicaciones realmente grandes. Las mayores burradas que yo he visto normalmente tienen más que ver con un análisis y diseño absurdo o especificaciones ridículas del cliente* que con una programación ineficiente.

*Cosas del tipo 'No le pongáis clave primaria a esas tablas que total, van a acceder dos gatos a ellas y ya ocupan demasiado espacio de por sí', como si la PK fuera a ocupar mucho más.

[#45 jmpep]

#17 A veces hay que llamar explícitamente a los destructores en C++, como por ejemplo cuando la gestión de momoria no se le deja al CLR y se usan cosas como el placement new y tal (http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.5).

En cuanto al código del constructor... qué raro que eso compilara. En GCC no lo hace, actualmente (acabo de probarlo de lo estrambótico que se me hacía. A fin de cuentas, aunque compilara, se está llamando al constructor desde dentro del constructor...).

[#22 Desactivado]

100 lineas no son nada, hay casos sobre todo en los metodos de mapeo de datos, que se sobrepasan las 100 lineas, pero si hay una cosa que define muy bien la calidad de un programa.

Como lei una vez: Si tus metodos necesitan mas de tres indentaciones, es una chapuza de codigo.

No sé quien dijo eso pero lo define perfectamente.

Cuando se empiezan a ver if, dentro de bucles que a su vez tienen mas if y mas bucles, sin saltar a otro metodo, eso es un infierno para leer y mantener, en temas de eficiencia ya no me meto.

[#7 npi]

Chapó

Ojalá todos los blogs fueran tan interesantes e ilustradores como este.

P.D.:¡¡¡Que poco valoramos el Copy&Paste!!!

[#17 Penetrator]

#13, #14 Veo tus métodos de 800 líneas, y subo a ficheros de más de 7.000 líneas.

En C++, he visto invocaciones explícitas de destructores. Es decir:

Bar::~Bar ()


Y lo más retorcido que he visto en un constructor:

Foo::Foo ()

[#20 Penetrator]

#15 Dividir un método grande en métodos más pequeños no es una cuestión de eficiencia, sino de legibilidad. En el caso que tú comentas, se podrían agrupar los campos de alguna forma y hacer un método para cada subconjunto de ellos. Sin embargo, sería un poco llevarlo al extremo, y en casos como este tampoco veo mal que se usen métodos grandes. Al fin y al cabo, tu método está haciendo una sola cosa.

El problema viene cuando un método hace muchas cosas más o menos complejas, utiliza 20 variables locales con nombres tan descriptivos como a, b, tmp, o similares, y ocupa 300 líneas de código sin un sólo comentario. Mantener semejante función es doloroso.

[#12 Penetrator]

#1 Veo tus 100 líneas, y subo a 400. He visto cosas que no creerías.

#8 No es algo moderno. Los métodos deberían tener pocas líneas de código. Una función de más de 100 líneas es señal de que algo va mal. Especialmente si no se trata de algo puntual.

[#36 joanmi]

#25: Ouch!! Eso duele....

...aunque si son capturadas no te extrañe que sea código generado dinámicamente para no complicarse con el js.

[#28 cptnniv]

Relacionada: ¿Por qué no se deben usar goto's al programar? La explicación teórica de Edsger W. Dijkstra de 1968, comentada. [ING]

¿Por qué no se deben usar goto's al programar? La ...

[#11 Desactivado]

¡Ah! ¡Qué tiempos!

IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION

RM sí que molaba, y no estas tonterías de hoy.

[#41 Tensk]

Dijsktra... Warnier... Orr... dios mio, no sé si es historia de la informática o una sucesión repetitiva de pesadillas informáticas de mi época de estudiante. Si alguien me hubiera dado otra opción a escoger en el COUndicional...

[#47 maxreaper]

Categoría GOTOS ya!!

[#14 Desactivado]

Venga. A ver quién la tiene más grande

[#37 maeghith]

:Mola // Arregla "ERROR: label 'Mola' not found" de #29

[#31 Desactivado]

Es interesante cuando habla de los diagramas de diseño de programas y dice: "Las pocas veces que Yo hago uno, me miran como si viniera de Marte… Quizá porque ahora son mucho más inteligentes que nosotros lo éramos y no lo necesitan." Bueno, ni unos tan listos ni los otros tan tontos, pero yo tengo claro que la formación en programación que se da hoy día es mucho mejor que la que recibieron ellos, simplemente porque las cosas han evolucionado y los métodos de enseñanza tambien (a veces se dan cosas muy teóricas, pero sirven para estructurar la cabeza). Hoy a la gente se la educa para hacer las cosas estructuradas de manera implícita, casi inconscientemente, cosa que no sucedía en tiempos del autor.

[#42 leonard_shelby]

#3 Es más, creo que querías decir "Uy,quería decir..."

Por otro lado, Forges genial como siempre. Oh wait...

[#25 Desactivado]

Subo a 10.000 líneas de javascript.

[#24 Kerensky]

#17 7000 líneas no está nada mal . Yo he visto una clase Java que tuvimos que refactorizar porque se pasaba del tamaño máximo permitido por la VM, que creo que son 32KB una vez generado el bytecode.

[#19 Kerensky]

#15 100 líneas no me alucinan. Como comentas, todo depende del caso, y los métodos de mapeo de cosas siempre son largos y repetitivos, lo que no es lo mismo que 100 líneas para realizar 10 operaciones completamente diferentes. Lo que si me alucinaron, como he dicho, son 800 líneas. Pero tienes razón, la única consecuencia de ese método fue que yo perdí un día entero de trabajo, mientras que una mala planificación o un mal diseño puede hacer perder varios meses de trabajo a decenas de personas (eso también lo he visto), pero lo que pasa es que esta noticia es de programación estructurada, no de diseño de aplicaciones.

Edito: P.D. Creo que eso que comentas se podría hacer por reflexión, o con generación automática de código.

[#13 Kerensky]

#12 Y yo subo a 800 líneas, con trozos enormes de código duplicado, copy & paste de otra parte del mismo método, y un return escondido dentro de una maraña de if's encadenados que me tuvo loco un día entero. Un método de "solo" 100 líneas no es tan raro de ver

[#32 in0de]

#31 Hombre, en mi empresa se siguen usando diagramas para el diseño de proyectos. Desde mi función concretamente uso componentes, clases y secuencia. Rara vez salgo de esos 3. Pero esos 3 siempre están en cada wiki de los proyectos de la empresa. Un proyecto sin documentación puede ser una locura muy gorda cuando hay cambios de compañeros que pasan de un proyecto a otro o surge una nueva incorporación.

Gracias a dios que hay gente que sigue usando los diagramas y cada vez abunda menos el compañero churrero con su tocho de sentencias y peléate para saber como se relacionan e interactuan los objetos entre ellos. Hay veces que cuando lees su código en vez de intentar entenderlo primero tienes que traducirlo.

[#29 Desactivado]

El GOTO Mola

[#23 VortixTM]

#20 Ya, igual que comenta #19, entiendo que realizar distintas operaciones complejas no es algo que se deba programar de manera secuencial. También me ha tocado pelearme con trozos de código ajeno que se convertía en ilegible por el mismo motivo, y sin confusión en las variables locales. A veces, cuando el código se empantana demasiado, es simplemente inviable un mantenimiento correcto.

En fin, creo que todos estamos de acuerdo en que el número de líneas de un método no es realmente indicativo de una buena o mala programación, sino lo que se hace realmente, la organización y (sobre todo) documentación de las mismas. Y en que a veces las especificaciones, herramientas y demás obligan a cierto tipo de errores.

[#38 jmanuelemus]

Voy a agregarlo como RSS Feed, por que el #%"#$&# proxy me bloquea por contener "demasiadas palabras". Y es que no me lo puedo perder

[#39 robespain]

Genial el speech del colega que escribe la entrada.

[#40 asturvulpes]

cuando yo studiaba se vislumbraba un horizonte que todos deseabamos que era la POO. Aquellas miles y miles de lineas cobol que depurar eran un horror y sobretodo si os toco el temible 2k, donde las empresas te pedian que les adaptases sus programas para el 2.000 temiendo que pasase como n el episodio de los Simpson donde se caian hasta los aviones. jejejeje:-D

[#21 Desactivado]

cuando empecé a estudiar programación en C y me empezaban a hablar de programación estructurada pensé que era imposible hacer mis antiguos juegos de spectrum en basic sin usar GO TOs... por ejemplo para hacer el típico "arkanoid". es decir ejecutar dos o mas bucles simultaneamente ...

[#43 Desactivado]

Interesantisimo como siempre.

[#18 Desactivado]

#15 fácil, poniendo todo el código en una sola...para algo están los ;

[#46 Naiyeel]

Esto me recuerda lo fácil que tenían mis profesores para corregir algunos exámenes, sobre todo de personas que habían salido ya de FP y venían a aprobar solo la asignatura de programación COBOL, etc.

Basicamente IF GOTO>0 THEN EXAMEN=0, vamos que te pillaban usando un GOTO y a volver el año que viene a probar suerte otra vez, aunque ya estuvieras años currando en una empresa programando en C o en clipper, que era lo que se movía en esos tiempos.

[#10 sapistri]

El papel que empezó la manía de la programación estructurada:

http://www.cs.ubbcluj.ro/~adriana/FP/Requirements/dijkstra68goto.pdf

Que además dió inicio a la frase "considered harmful" que no ha parado de repetirse desde entonces.

[#48 Desactivado]

#30
oh yeah, pascal... Lo recuerdo con nostalgia.