Padrões de nomenclatura em COBOL: como escrever código que dura décadas

Se você já abriu um programa COBOL e teve dificuldade para entender o que ele fazia, é bem provável que o problema não estava nem na lógica nem na linguagem. Provavelmente, o problema estava nos nomes.

Variáveis genéricas, parágrafos que não dizem nada, parâmetros que você não sabe de onde vieram… tudo isso transforma a manutenção em um risco.

E isso não é um problema do COBOL. É um problema de quem escreveu o código.

E em COBOL, mais do que em muitas outras linguagens, nome bem escolhido não é detalhe. É o que mantém o sistema vivo por décadas.

Não existe “o melhor padrão”

Antes de falar de padrões, tem um ponto importante aqui: o melhor padrão de nomenclatura é o padrão adotado pela empresa.

Não existe um modelo universal. Cada empresa construiu o seu ao longo do tempo. E, em sistemas legados, é comum encontrar variações — afinal, muitos programadores passaram por aquele código ao longo dos anos.

Mesmo assim, quase sempre existe algum padrão predominante.

E a melhor decisão, na prática, é simples: identifique o padrão e siga ele.

Por que sistemas legados adotam alguns nomes com apenas 8 caracteres?

Se você já trabalhou com COBOL em ambiente de mainframe, provavelmente percebeu que muitos nomes têm no máximo 8 caracteres.

Isso vale para programas, jobs, procs, copybooks… E isso acontece porque esses componentes são armazenados como membros em datasets particionados, também chamados de PDS ou PDSE.

E nesses datasets, o nome do membro tem um limite de 8 caracteres.

Na prática, isso significa que o nome do programa é o nome do membro, e a mesma coisa acontece com jobs, procs e copybooks.

Essa limitação acabou influenciando toda a forma como os sistemas foram nomeados — e esse padrão continua presente até hoje. Mas não é uma limitação da linguagem. É uma característica da arquitetura do ambiente.

Um exemplo típico de nomenclatura

Um padrão comum em empresas é dividir o nome do programa em partes, por exemplo…

AEAP0102

Esse tipo de nome pode carregar várias informações:

• Sigla do sistema: AEA – Análise Estatístico Atuarial
• Tipo de componente: P=Programa, J=Job, C=Copybook, A=Arquivo
• Módulo: 01=Manutenção, 02=Consultas, 03=Relatórios, 04=Interfaces
• Funcionalidade específica: 01=Patrocinadoras, 02=Índices Econômicos, 03=Índices Demográficos

Ou seja, quem está acostumado com o padrão da empresa bate o olho e sabe que AEAP0105 é um programa, que faz  parte do sistema de Análise Estatístico Atuarial, e é responsável pela manutenção de índices econômicos.

Cada empresa organiza isso de um jeito, mas a ideia é sempre a mesma: o nome carrega significado.

O problema mesmo está dentro dos programas

Os nomes internos usados pelo programa são ainda mais importantes que os nomes externos.

Veja este exemplo:

COMPUTE V2 = V1 * X1
IF V2 > 0
    COMPUTE V3 = V2 - V1
    PERFORM GRAVA
END-IF

Esse código funciona. Mas ninguém sabe exatamente o que ele faz. E daqui a uns 10 anos ninguém saberá com certeza.

Agora compare com:

COMPUTE WT-VR-DESCONTO = WT-VR-BRUTO * WT-TX-DESCONTO
IF WT-VR-DESCONTO > ZEROS
    COMPUTE WT-VR-LIQUIDO = WT-VR-BRUTO - WT-VR-DESCONTO
    PERFORM 21-GRAVA-VALOR-LIQUIDO
END-IF

Aqui, mesmo sem comentários (que eu recomendo fortemente que sejam usados ao máximo), o código já se explica, e essa é a diferença que um bom padrão de nomenclatura faz.

O COBOL permite nomes relativamente longos (até 30 caracteres, dependendo do compilador). Use a pista toda! Isso não é um detalhe, é uma oportunidade para dar significado extra ao código e fazê-lo durar.

Nomes de variáveis

Uma prática comum é usar prefixos para indicar o tipo de variável. E alguns prefixos são clássicos:

Prefixo	Tipo de variável
WT-	Variável de trabalho
WC-	Constante
WV-	Tabela interna ou item de tabela interna
WR-	Relatórios
LK-	Parâmetros recebidos na Linkage

Também é bastante comum definir siglas para indicar o tipo de conteúdo das variáveis:

Sigla	Tipo de conteúdo
-VR-	Valor
-TX-	Taxa
-CD-	Código
-NR-	Número
-NM-	Nome
-DS-	Descrição
-DT-	Data
-HR-	Hora

Essa prática permite que qualquer um, hoje ou no futuro, entenda o tipo e o propósito da variável apenas lendo seu nome:

Exemplos:

WS-NR-ALUNO
WT-TX-JUROS
WV-CD-BANCO
WR-NM-CLIENTE
LK-DT-VENCIMENTO
WR-HR-EMISSAO

Na FILE SECTION nomes também importam

A nomenclatura não deve parar na Working Storage. Na FILE SECTION, nomes de arquivos, registros e campos também precisam seguir um padrão.

Eu, por exemplo, gosto de prefixar o nome de registros e campos com o mesmo nome do arquivo.

Por exemplo, se o arquivo se chama SBA0103, eu criaria a FD assim:

FD SBA0103.
01 SBA0103-REGISTRO.
    03 SBA0103-NR-CLIENTE PIC 9(006).
    03 SBA0103-NM-CLIENTE PIC X(030).
    03 SBA0103-TP-PESSOA  PIC X(001).

E se lá na PROCEDURE, eu encontrar um comando…

MOVE SBA0103-NR-CLIENTE TO WT-NR-CLIENTE-ANTERIOR

…qualquer um saberá de onde veio o número do cliente.

E aqui vale o mesmo princípio: o padrão pode variar, mas precisa existir.

Nomes de parágrafos

Esse é um dos pontos onde mais existe variação entre empresas, mas também é um dos mais importantes.

É importante evitar nomes genéricos como…

PAR1
ROTINA-A
TESTE

É altamente recomendável usar nomes que indiquem claramente a finalidade do parágrafo, como em…

CALCULA-TAXA-DESCONTO
GRAVA-VALOR-LIQUIDO
LE-PROXIMO-CLIENTE

Quase sempre as empresas adotam algum prefixo no nome dos parágrafos para fornecer informações sobre a estrutura do programa. Por exemplo, 211-CALCULA-TAXA-DESCONTO indica que esse parágrafo está sendo chamado por algum parágrafo cujo prefixo é 21-.

Conclusão

Código que não se explica não sobrevive, e sistemas escritos em COBOL continuam por aí também por isso.

Nesse contexto, o código precisa ser legível não só hoje, mas principalmente no futuro. Nome ruim não é só um problema estético; é um problema operacional que no final das contas afeta estabilidade, produtividade e, consequentemente, custo.

Qualquer um pode escrever um programa que funciona.

Mas alguns escrevem programas que continuam funcionando ao longo do tempo.

---