[Sintaxis] Escritura distinta de un programa COBOL

[Kuk]

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

1. el nombre de una clase debe ir con mayúscula
2. el nombre de un método debe ir con minúscula
3. etc.

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.

[Nitzer]

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.

WORKING-STORAGE SECTION.
01  VARIABLES.
    02  CONTADOR PIC 9(8).
    02  OPCION   PIC 9.
    02  VALOR PIC 99.
PROCEDURE DIVISION.
    INITIALIZE VALOR
    PERFORM VARYING CONTADOR FROM 1 BY 1 UNTIL CONTADOR > 10
       DISPLAY 'LO QUE SEA'
       ADD 1 TO VALOR
       EVALUATE OPCION
          WHEN 1 DISPLAY 'OPCION 1'
          WHEN 2 DISPLAY 'OPCION 2'
       END-EVALUATE
     END-PERFORM

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.

[Kuk]

@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

[Nitzer]

❞ @Nitzer, yo lo pongo en una línea separada para que se le vea bien al jodio

[Josber]

❞ @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

Qué tiempos aquellos del COBOL-74, ahí si que tenias que montar unas historias de 3 pares de ... para poder "librarte" o terminar un IF, un READ - NEXT, etc, todo a base de PERFORM y el "maldito" GO TO y, sobre todo de muuuuuucha imaginación, o usabas el punto (.) al final de una instrucción o te pegabas una panzada a revisar código de varios días y, el tema de más de una instrucción por línea, era impensable, bastante te costaba seguir tu código bien escrito, como para seguir y leer código ajeno, vamos, ni por suerte

Un salu2.-

[Kuk]

@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:

1. En la PROCEDURE (equivalente de Main) - debemos ver los párrafos describiendo qué hace el programa y en qué orden (NO el cómo lo hace). Así al llegar al "main", con una ojeada rápida ya veo si es el programa que me interesa o no. Así que el Main sólo debe contener llamadas a párrafos, nada de instrucciones MOVE, CALL, ADD etc.
2. Para ver el cómo hace lo que hace el programa, ya iremos a los párrafos concretos que se llaman desde el Main (para ver los detalles).
3. Máximo nivel de performs anidados: 3
4. Máximo nivel de IFs anidados: 3
5. Máximo nivel de capas de software: 3 (Orquestrador, Rutina funcional, Rutina técnica/Accesor)
6. Indentación obligatoria
7. NADA de puntos, un sólo punto al final del párrafo en línea separada
8. NADA de THRU en PERFORM ni párrafos con nobmre-parrafo-EXIT
9. NADA de secciones
10. NADA de GO TO salvo párrafo de ABEND
11. Programa nuevo: máximo 1500 líneas. Nueva función grande = nuevo programa + CALL
12. Respetar los tipos de campo numérico según plataforma (COMP-5 para Intel X86_64, COMP-3 para IBM Z etc.)

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.

[Gusaiello]

@Kuk, y que tal si a la mitad del programa te pongo un ALTER?
Supongo que en ese preciso momento me quedo sin trabajo, no?

[Josber]

❞ , y que tal si a la mitad del programa te pongo un ALTER? Supongo que en ese preciso momento me quedo sin trabajo, no?

¡¡Eso, eso!!, un ALTER con un GO TO ... DEPENDING ON a la sexta línea del programa y otro a falta de 6 líneas para terminar, esas instrucciones, sí que eran una pasada , la madre que las ...

[Fito]

Noooooooo Amigosssss...

Larga vida al GO TO....

Yo trato de armar código estructurado, pero un buen GO TO bien puesto, no tiene precio...

Saludos...

Fito...

[Kuk]

@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