|
Escritura distinta de un programa COBOL
Hola queridos Amigos y Colegas, estoy aquí nuevamente para compartir una inquietud muy especial en cuanto al tipo de escritura de un programa cobol, si, tipo de escritura, y pasare a explicar el tema.
En una escritura normal de un programa y dependiendo del dialecto cobol que se use como compilador, la forma estándar o básica o de reglamento si se puede decir así seria la siguiente (Ejemplo simple) Código COBOL:
Ahora, el tema es el siguiente, debido a que uno quiere ahorrar linea de programación, o achicar el programa cobol para tener menos lineas así pueda ser compilado con mas instrucciones y menos lineas se haría esto: Código COBOL:
Que opinan de esto?, déjeme contarles que Yo, puedo hacer esto usando Micro Focus Cobol, creo que hay una instrucción o paramento o algo que le indica al lenguaje que interprete una linea conteniendo varias instrucciones y no solo una. Siempre aprendimos que en cada linea va una definición de variable o archivo o tabla y también un procedimiento por linea, pero como vemos aquí, en una linea hay varias definiciones y procedimientos, como fije antes, En Micro Focus Funciona y muy bien, esto me ayudo a crear programas mas grandes, con mas contenido de definiciones y procedimientos y a la vez con menos lineas o renglones para compilar. La pregunta iría dirigida a todos los demás lenguajes o mejor dicho a todos los dialectos de cobol, como AcuCobol, RmCobol, IbmCobol, etc, etc, etc. Mas en particular me gustaría saber si en AcuCobol se puede indicar de algún modo mediante paramentos o condiciones al compilador o al entorno para que interprete esta forma de trabajo, actualmente dan error al compilar. Seria bueno que hagan pruebas con sus lenguajes y comenten que descubrieron y si encuentran o saben como hacer que los demás dialectos interpreten esto comenten , es importante conocer este tema y compartir con los demas. Atte Jorge. |
A ver @jorgeamedina2020, sin que lo consideres un insulto porque nada más lejos de mi intención, me parece esa forma de escribir código "una marraná", a parte de que se quedaría el programa poco claro a la hora de leerlo por ti o por cualquier otra persona, también te digo que, en la PROCEDURE DIVISION, puedes escribir el código casi como quieras, pero la WORKING, tiene unas normas muy estrictas, una de ellas es que "Todo campo a nivel 77 ó 01, ha de empezar en el área A", o lo que es lo mismo, en las columnas 8 a 11, si en vez del COBOL actual, usaras COBOL-74 o COBOL-85, no te funcionaría ni de suerte, en esas versiones, tenías que respetar mucho las áreas A B y C, (columnas 8 a 11, 12 a 72 y 73 a 80 respectivamente).
Por otro lado, imagínate que haces un programa de esa manera y, dentro de seis meses, un año, cuando sea, necesitas modificar algo, te vas a volver loco intentando encontrarlo. El profesor que yo tuve de COBOL, a mediados de los 80, lo tenía muy claro, tu programa podía trabajar mejor que ninguno pero, como no estuviese escrito claro, con sus indentaciones, sus espacios, cambios de línea, comentarios, etc, estabas suspendido. Sólo tienes que descargarte cualquiera de los ejemplos que yo he subido y verás que es casi obsesivo en mí poner indentaciones, saltos de línea, etc, sin importar el largo del programa, eso es lo de menos hoy en día, el compilador, lo va a leer como si fuese un churro todo seguido y creo que nadie se me ha quejado por eso. Un salu2.- |
@Josber, Hola, gracias por tu respuesta sincera, primero no me parece que mi escritura sea (una marrana), segundo son mis programas y nadie debería verlos o acceder mas que yo porque son de mi propiedad intelectual y tercero con respecto a las normas... porque mi compilador me lo permite hacer?, buena pregunta verdad!!!,
Este ejemplo que te comparto lo hice hace varios años atrás, y justo ahora salio una modificación y se hizo al toque sin demorar nada, por que?, por conozco mis programas como los hice, asi de facir. Mira esto: Código COBOL:
|
@jorgeamedina2020, es que el segundo ejemplo que has puesto, está correctamente escrito, con sus saltos de líneas, sus espacios, cada cosa en su sitio, pero el ejemplo del primer post
Cita:
Salu2.- |
@jorgeamedina2020, yo estoy con @Josber.
Los programas deben de estar lo mas claro posibles. Los programas que yo hago son propiedad de la empresa que me paga por ello y además deben de poder comprender el resto de programadores que trabajan para la misma empresa. Si quiero quitar líneas o información redundante lo meto en copys. Y dentro de copys puedo tener copys. Tengo programas que modifican programas ya hechos ( analizadores - cambiadores ) y el resultado debe de ser lo mas claro posible para otro programa que venga cambiando cosas o programadores que vengan cambiando cosas. Te podría decir mas cosas, pero en lo que apuntas no veo nada positivo. |
@jorgeamedina2020, hablando de estilo de programación si me lo permites....
esto: Código COBOL:
Son 5 grupos de 6 campos iguales (30 variables). Eso yo lo meteria en una tabla. (occurs) esto: Código COBOL:
un evaluate. esto que lo tienes repetido 20 veces con etiquetas diferentes: Código COBOL:
se hace un perform general con condiciones. esto: Código COBOL:
Lo tienes repetido un monton de veces. Pues lo mismo un perform a INA-GENERAL y quitas 100 lineas O sea que hay que hacer cosas generales, con condiciones y no repetir siempre lo mismo. |
@JCantero, Comprendido su punto de vista
- - - Updated - - - @JCantero, Si, estoy de acuerdo, conozco esa forma de trabajo tambien. lo hice en algunos de mis programas |
El primer ejemplo que subí fue algo sencillo para mostrar o explicar el tema de usar en un solo renglón dos o mas definiciones o dos o mas procedimientos, solo eso.
Es por eso que querían que UDs prueben esto en su lenguaje, por supuesto respetando desde la columna 8 a la 72. Es solo prueba y comprensión. El segundo ejemplo (que no es un ejemplo), es parte de un programa que hace estadísticas de ventas tomando archivos de movimientos y creando pantallas e impresiones. Aquí quería mostrar que uso mucho varias variables con nombres distintos y con longitudes distintas, y que las fui escribiendo una a lado de la otra, separaras por el punto. El punto separa instrucciones y no el fin de linea. Lo mismo hice en la sección de procedimientos, puse en una linea varias tareas, intento con esto usar toda la linea posible para escribir todo lo que pueda para no hacer largo el programa, esto esta bien, mi compilador Micro Focus Cobol Version 3.00 del año 1989 lo permite, lleve el mismo programa para compilar con Acucobol y no le gusto que escribiera así las lineas, lo mismo me paso con GnuCobol en una de sus versiones. No intento Discutir el tema ni estar en contra de nadie, mi idea de esto es mostrar o compartir una forma de trabajo y saber si otros lenguajes se los permiten, meramente informativo queridos colegas. - - - Updated - - - Ademas imagino que algún parámetro o referencia o variable de entorno permite este tipo de escritura, la idea principal fue saber que lo permite... |
Hola Amigos:
Estuve probando con PowerCobol. Los niveles 01 y 77 necesariamente los quiere en la columna 8. Los niveles 02 en adelante se pueden poner uno al lado del otro, separado por puntos. En la Procedure los comandos pueden ponerse a continuación en la misma lína, separados con puntos o sin ellos. Las Instrucciones #include tambien pueden ponerse en la misma línea. La claridad del código es indispensable, ya sea para retomar algún programa viejo o para que otros puedan leer nuestro código. Pero como sobre gustos no hay nada escrito, cada uno tiene que tomar la forma que le resulte conveniente, por ejemplo yo programo en minúsculas, me cuesta seguir un código escrito en mayúsculas. Respetar las indentaciones me parece fundamental, para seguir las estructuras. Yo pierdo mucho tiempo en tratar de tener un código claro, alineando por picture por ejemplo. Eso me ayuda mucho para cuando tengo que encontrar errores o tengo que realizar alguna modificación. Los objetos les pongo un prefijo siempre, no dejo el "name" que le pone el editor. Todos mis cuadros de texto empiezan con txt... los combos con cmb... las etiquetas con lbl, etc. Y después le sigue un nombre nemotécnico que me indica qué contiene, txtNombre, txtApellido, etc. Los campos de los archivos tambien les pongo un prefijo de tres o más letras que lo saco de una pseudo abreviatura del nombre del archivo. El archivo de cuentas corrientes se llama CTACTE y el campo nombre se llama ccnom, cctelef, cccuit. cccodpos. etc. Las propiedades y métodos tambien trato de respetar como se escriben, porque en la mayoría de los objetos como se escriba es los mismo, pero pueden haber controles activex que necesariamente tengan que respetarse las mayúsculas o minúsculas. Entonces trato de acostubrarme. "SetFocus", "Value", "BackColor", "ForeColor", "CallForm", "OpenForm". Todas estas nomenclaturas para escribir el código, lo he ido desarrollando con el tiempo, por eso por ahi tengo mezcla si comparamos programas viejos con nuevos. Y a veces un programa nuevo que haya hecho un copiar y pegar de uno viejo, en la medida que el tiempo me de, trato de "traducirlo". Saludos... Fito... |
Cita:
@jorgeamedina2020, eso es standard de cobol, hasta el rmcobol 5.35 lo admite (AÑO 1985). Mientras te ciñas a los márgenes, puedes poner las líneas que entren. En la actualidad, cada compilador tiene opciones o parámetros de escribir después de la columna 73 sin ceñirte a los márgenes. Con lo cual puedes aprovechar mucho mas tu forma de escribir los programas. |
@jorgeamedina2020, compañero, esto de meter más de una sentencia en la misma línea es bastante mala idea. A lo largo de los años la gente ha ido adquiriendo experiencia y generando sabiduría basada en ella. Si escribimos una sentencia por línea es por algo. Y ese algo es que es la manera más rápida y fácil de analizar código sin tener que leerse todas y cada une de las líneas del código, que al fin y al cabo es código no Shakespeare. :D ;)
Es decir que viendo el principio ya sabes si forma parte de lo que buscas o no. Así que, yo te aconsejo no reinventar la rueda, aunque técnicamente puedes hacerlo como te da la gana (casi), hay unas convenciones, reglas, y hasta podríamos llamarlo cultura. En como en Java por ejemplo, por convención:
Esto no quiere decir que no lo va a compilar si pones el nombre de la clase con minúscula o todo mayúsculas. Pero, estas pequeñas reglas respetadas por la gran mayoría ayudan a la hora de codificar, buscar y corregir errores etc. |
Hola compañeros, independientemente de que un compilador permita o no cierta sintaxis, yo siempre programa de una forma estructurada, nunca utilizo punto al final solo si hay párrafos.
Mantengo un sangrado de 3 columnas, utilizo mas EVALUATE que IF, no utilizo NUNCA el comando GO. Cuando programo en PowerCobol, procuro no escribir mucho en los eventos, si va a haber mucho código, prefiero llamar a un procedimiento mas explicativo. Código COBOL:
es un código sin sentido :), pero era para mostrar como lo hago. Y lo del punto al final de cada línea os digo que no lo utilizo, y tengo procedures de miles de líneas. |
@Nitzer, lo de los puntos es un sarcoma del que hay que deshacerse, eso viene de cuando los END-IF, END-EVALUATE y el resto de los END-* no existían (antes del estándar AN74). Efectivamente, hay que utilizar sólo un punto al final del párrafo, yo lo pongo en una línea separada para que se le vea bien al jodio
|
Cita:
|
Cita:
Un salu2.- |
@Josber, efectivamente. Además, no hay que olvidar que la lectura del programa debe ser fácil y la estructura debe permitir hacerlo de manera rápida.
Yo he creado en más de una empresa los estándares de codificación en Cobol, cuyos puntos clave siempre han sido:
Creo que no se me olvida nada de los puntos importantes. Esto se lo hago aprender como los 10 mandamientos a los DEVs, y hasta pongo controles en Jenkins de ciertas cosas cuando el Build para comprobarlo automáticamente y como haya cosas que no me cuadran - ABEND como una casa. :D |
@Kuk, y que tal si a la mitad del programa te pongo un ALTER? :loco:
Supongo que en ese preciso momento me quedo sin trabajo, no? |
Cita:
|
Noooooooo Amigosssss...
Larga vida al GO TO.... Yo trato de armar código estructurado, pero un buen GO TO bien puesto, no tiene precio... :mola::mola: Saludos... Fito... |
@Fito, esto es lo que se llama "código espagueti" que con cada intervención la complicación se multiplica en progresión geométrica. En tu caso, como sólo eres tú el que toca el código, todavía. Pero como te toque hacer fix de un bug en el mundo de banca/seguros, donde el mismo programa lo han tocado ya 45 bigardos pensando en cerrar lo antes posible la incidencia... Te aseguro que la baja por depresión la tienes garantizada :D :D :D
|
Cita:
@Gusaiello, he tenido que ser buena persona en mi vida anterior porque nunca he visto un ALTER en producción. De hecho nunca lo he probado. Creo que era algo tipo que el programa se recompilaba a si mismo en un trozo ¿no? Menuda flipada..... :shok: |
@Kuk,
Código COBOL:
Cuando el programa pasa por el ALTER toda mención que se haga al párrafo tal es redireccionada al párrafo cual. Y anda a seguir la lógica de ese programa!!!! |
@Gusaiello, ya te digo, por algo no lo he visto nunca... para los crackers debe ser la hostia, pero para los simples mortales como nosotros, seguir un programa como ese es equivalente a un doctorado en neuroredes :astro: :marea: :vacuna:
|
| La franja horaria es GMT +2. Ahora son las 16:22. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.