Do que estou falando? Do caos atrás dos teclados, devido a instabilidade dos primeiros anos da computação com softwares imprecisos e os gastos milionários em CPDS. Esse termo foi cunhado na década de 70 do século passado e até hoje motiva muita discussão entre acadêmicos e profissionais.
Leia na InTEGRA
✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Mostrar mensagens com a etiqueta go to. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta go to. Mostrar todas as mensagens
quarta-feira, 3 de janeiro de 2024
domingo, 2 de maio de 2021
Spaghetti Code Rules: Quando um Programador COBOL Descobriu que a Matrix Era Feita de Espaguete e Cada GO TO Criava um Novo Labirinto
 |
| Bellacosa Mainframe e o spaghetti code rules |
☕ Um Café no Bellacosa Mainframe
Spaghetti Code Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Era Feita de Espaguete e Cada GO TO Criava um Novo Labirinto
"A Matrix não aprisionava apenas pessoas. Ela também aprisionava programas dentro de um emaranhado de caminhos onde ninguém mais sabia como chegar à saída."
Prólogo — O Labirinto Invisível da Matrix
Neo acabara de receber uma missão aparentemente simples.
Corrigir um erro no cálculo dos juros de um financiamento.
Morpheus entregou um único arquivo.
FINANCEIRO01.CBL
Neo sorriu.
— Apenas um programa?
Morpheus respondeu.
— Sim.
Só um.
Neo abriu o código.
A barra de rolagem diminuiu.
Muito.
Muito mesmo.
O programa possuía:
68.000 linhas
2.400 parágrafos
centenas de
GO TOdezenas de
ALTERmilhares de variáveis
comentários escritos por gerações diferentes
Neo tentou localizar a regra do financiamento.
Cinco minutos depois...
estava em outra rotina.
Dez minutos depois...
entrou em um PERFORM.
Depois um GO TO.
Depois outro.
Depois um PERFORM THRU.
Depois um ALTER.
Depois um EXIT.
Depois voltou.
Depois foi para outro programa.
Depois retornou.
Finalmente perguntou:
— Morpheus...
onde exatamente começa esse cálculo?
Morpheus sorriu.
— Essa pergunta já foi feita por pelo menos cinquenta programadores antes de você.
O Oráculo apareceu.
Olhou para Neo.
E disse:
"Você não entrou apenas em um programa. Entrou em um prato de espaguete."
O que é Spaghetti Code?
Spaghetti Code (Código Espaguete) é um antipadrão de software caracterizado por uma estrutura extremamente confusa, onde o fluxo de execução é difícil de compreender, seguir ou modificar.
O nome vem da aparência do fluxo lógico.
Imagine um prato cheio de espaguete.
Os fios cruzam-se em todas as direções.
Você tenta puxar um.
Leva metade do prato junto.
No software acontece exatamente igual.
Uma alteração aparentemente simples afeta dezenas de outras partes.
A origem do termo
O termo surgiu na década de 1970.
Naquela época muitos sistemas eram escritos utilizando:
GOTO
Jumps
Branches
Fluxos não estruturados
Os diagramas de execução pareciam literalmente um prato de macarrão.
Daí nasceu o nome.
Matrix explica melhor que qualquer livro
Imagine que Neo precisa chegar até o Arquiteto.
Mas cada corredor leva para outro corredor.
Cada porta abre outra porta.
Cada elevador muda de direção.
Cada escolha cria um novo caminho.
Após meia hora...
Neo percebe.
A Matrix inteira virou um labirinto.
É exatamente essa sensação que um desenvolvedor experimenta ao abrir um sistema com Spaghetti Code.
O nascimento do espaguete
Curiosamente...
ninguém acorda pensando:
"Hoje vou criar um código horrível."
O Spaghetti Code nasce lentamente.
Primeiro.
Um pequeno ajuste.
Depois.
Outro.
Depois.
Uma exceção.
Depois.
Uma regra temporária.
Depois.
Outra urgência.
Depois.
Uma correção rápida.
Cinco anos depois...
o prato está servido.
Um exemplo COBOL
Imagine este fluxo.
INICIO
↓
VALIDA
↓
CALCULA
↓
GRAVA
↓
FIM
Bonito.
Agora imagine vinte anos depois.
INICIO
↓
VALIDA
↓
GO TO ROTINA-X
↓
PERFORM Y
↓
ALTER Z
↓
GO TO A
↓
PERFORM THRU B
↓
ROTINA-C
↓
GO TO D
↓
VALIDA NOVAMENTE
↓
VOLTA
↓
FIM
Ninguém mais entende.
Como surge?
Existem várias causas.
Crescimento contínuo
Programa pequeno.
Depois médio.
Depois enorme.
Falta de arquitetura
Cada desenvolvedor cria sua própria organização.
Pressão por prazo
"Depois organizamos."
Nunca organizam.
Excesso de GO TO
O clássico dos clássicos.
Código duplicado
Trechos espalhados.
Ausência de revisão
Ninguém verifica consistência.
O COBOL é culpado?
Não.
Essa talvez seja a maior injustiça da história da computação.
COBOL moderno incentiva:
PERFORM
Modularização
COPYBOOK
CALL
Programas estruturados
Classes
Métodos (Enterprise COBOL moderno)
O problema nunca foi COBOL.
Foi a forma como algumas pessoas programaram.
Matrix Reloaded
O Arquiteto mostra milhares de versões anteriores da Matrix.
Cada versão acumulava pequenos remendos.
Nenhum parecia perigoso.
Todos juntos criaram enorme complexidade.
Software evolui exatamente assim.
O efeito psicológico
Existe uma armadilha.
Quando modificamos um programa conhecido.
Pensamos:
"Vou colocar só mais um IF."
Depois outro.
Depois outro.
Cada alteração parece pequena.
A soma delas não é.
O Programador COBOL Padawan
Todo Padawan abre um programa antigo e pensa.
"Vou entender rapidamente."
Uma hora depois.
Ainda tenta descobrir onde começou.
O Agente Smith adora Spaghetti Code
Porque sistemas confusos criam:
medo.
Ninguém gosta de alterar.
Cada mudança parece perigosa.
Smith nem precisa atacar.
O próprio código afasta os desenvolvedores.
Um exemplo inspirado na Matrix
Imagine que Neo precisa abrir uma porta.
Mas antes precisa:
abrir outra.
Depois outra.
Depois voltar.
Depois pegar uma chave.
Depois retornar.
Depois abrir outra porta.
É exatamente isso que acontece em muitos fluxos de programas antigos.
Como reconhecer?
Existem sinais claros.
Muitos GO TO
Principal indicador.
Programas enormes
30 mil.
50 mil.
100 mil linhas.
Variáveis sem significado
A1
B2
X99
WK01
WK02
WK03
Regras espalhadas
Mesmo cálculo aparece em cinco lugares.
Dependências circulares
Programa chama outro.
Que chama outro.
Que volta ao primeiro.
Um caso realista
Imagine.
Sistema bancário.
Criado em:
Mais de:
400 modificações.
Nenhuma refatoração.
Resultado.
Cada alteração exige:
dois analistas
três programadores
uma semana de testes
Não porque a regra seja difícil.
Mas porque ninguém sabe o impacto.
Os riscos
Bugs
Alteração pequena.
Impacto gigante.
Performance
Fluxo desnecessário.
CPU
Mais instruções.
Mais custo.
Manutenção
Tempo explode.
Onboarding
Novos profissionais sofrem.
Burnout
Especialistas tornam-se gargalos.
O custo invisível
Imagine.
Alteração.
15 minutos.
Mas entender o programa leva:
dois dias.
Isso é custo.
O impacto no Mainframe
Mainframe processa:
milhões de transações.
Spaghetti Code aumenta:
CPU
consumo
risco
testes
tempo de homologação
Tudo fica mais caro.
Existe ferramenta para medir?
Sim.
Hoje existem ferramentas excelentes.
IBM ADDI
IBM Application Discovery
SonarQube
IBM COBOL Check
IBM Developer for z/OS
Enterprise Analyzer
Elas calculam:
complexidade ciclomática
dependências
acoplamento
fluxo
Como evitar?
Modularização
Divida responsabilidades.
PERFORM
Prefira estruturas claras.
CALL
Separe funcionalidades.
COPYBOOK
Padronize estruturas.
Refatoração contínua
Não espere dez anos.
Comentários úteis
Explique:
por quê.
Não:
o quê.
Testes
Protegem refatorações.
Atenção!
Existe diferença entre:
Programa grande
e
Spaghetti Code.
Alguns sistemas possuem:
200 mil linhas.
Mas excelente organização.
Outros possuem:
2 mil linhas.
Completamente caóticos.
O tamanho não define qualidade.
O papel da arquitetura
Arquitetura cria limites.
Cada módulo possui função.
Sem arquitetura.
Tudo conversa com tudo.
Matrix e os Sentinelas
Os Sentinelas encontram Zion porque seguem caminhos claros.
Imagine se existissem milhões de túneis aleatórios.
Eles demorariam muito mais.
Código também.
Fluxos claros facilitam manutenção.
Curiosidade
A Structured Programming Movement dos anos 70 surgiu justamente para combater o Spaghetti Code.
Nomes como:
Edsger Dijkstra
Niklaus Wirth
Donald Knuth
mudaram completamente a forma de programar.
O famoso artigo:
"Go To Statement Considered Harmful"
transformou a indústria.
O COBOL moderno
Enterprise COBOL oferece recursos para escrever código extremamente limpo.
Inline PERFORM
EVALUATE
Functions
Nested Programs
OO COBOL
User Defined Functions
XML
JSON
Não existe desculpa para criar espaguete.
Erros clássicos
Misturar regras de negócio e acesso a dados.
Usar GO TO excessivamente.
Duplicar lógica.
Não remover código morto.
Acrescentar IFs infinitamente.
Não modularizar.
Boas práticas
Uma responsabilidade por módulo.
Nomes significativos.
Fluxo previsível.
Revisões frequentes.
Refatoração incremental.
Diagramas atualizados.
Documentação viva.
O Ensinamento do Oráculo
O Oráculo entrega um prato de espaguete para Neo.
Ele tenta puxar um fio.
Todo o prato vem junto.
Ela então entrega uma caixa organizada de peças LEGO.
Cada bloco possui uma função.
Ela sorri.
"Software deve parecer LEGO.
Nunca espaguete."
Aplicabilidade
Spaghetti Code aparece em:
COBOL
Java
Python
C
C++
JavaScript
PHP
Rust
Go
Assembly
Nenhuma linguagem está imune.
Lições para um Programador COBOL Padawan
Quando você começar sua carreira em um ambiente IBM Z, encontrará programas escritos há décadas. Alguns serão verdadeiras obras-primas da engenharia. Outros parecerão um labirinto digno da Matrix.
A tentação será adicionar "apenas mais um IF" ou "mais um GO TO" para resolver rapidamente um incidente. Resista.
Sempre que possível:
extraia responsabilidades para novos módulos;
elimine duplicações;
substitua fluxos confusos por estruturas claras;
escreva nomes compreensíveis;
documente regras de negócio;
mantenha testes atualizados.
Cada pequena melhoria reduz um pouco o emaranhado do espaguete e facilita o trabalho do próximo desenvolvedor.
Conclusão — Saindo do Prato de Espaguete da Matrix
No final da trilogia Matrix, Neo percebe que compreender a estrutura da Matrix é mais poderoso do que simplesmente reagir a ela.
Na Engenharia de Software, acontece exatamente o mesmo.
O maior problema do Spaghetti Code não é ser feio.
É transformar cada alteração em uma aventura imprevisível.
Em sistemas COBOL responsáveis por processar milhões de transações financeiras, isso significa mais tempo de manutenção, maior risco de incidentes, consumo adicional de CPU, testes mais demorados e equipes receosas de evoluir o software.
No universo Bellacosa Mainframe existe uma máxima que todo Programador COBOL Padawan deveria guardar:
"Cada
GO TOdesnecessário é mais um corredor dentro da Matrix. Cada módulo bem organizado é uma porta de saída."
O objetivo não é escrever o código mais inteligente.
É escrever o código que outro programador — talvez você mesmo daqui a dez anos — consiga entender sem precisar da ajuda do Oráculo.
Porque o verdadeiro Escolhido não é aquele que cria o maior labirinto.
É aquele que sabe construir o caminho mais simples até a solução.
domingo, 13 de setembro de 2015
🧠 Structured Programming (Dijkstra) — A Revolução Silenciosa que Salvou o Software
 |
| Bellacosa Mainframe fala sobre o legado Dijkstra : Structured Programming |
🧠 Structured Programming (Dijkstra) — A Revolução Silenciosa que Salvou o Software
☕ Um Café no Bellacosa Mainframe
Nos primórdios da programação, escrever código era mais parecido com montar uma gambiarra elétrica do que com engenharia. Fios cruzados, saltos imprevisíveis e um único erro podia derrubar tudo. Foi nesse caos que surgiu uma ideia simples — e revolucionária:
💡 Programas deveriam ser estruturados, previsíveis e compreensíveis.
O nome por trás dessa virada?
👉 Edsger W. Dijkstra — um dos maiores gênios da computação.
🏛️ Antes da Revolução: O Velho Oeste do Código
Programas eram gigantescos blocos lineares
Cheios de saltos incondicionais
Manutenção era um pesadelo
Bugs eram quase impossíveis de rastrear
O principal culpado? 😈
👉 O famigerado GOTO
Um comando que dizia:
“Pare o que está fazendo e vá executar ali no meio do programa.”
Resultado: o famoso spaghetti code 🍝
💣 A Carta que Mudou Tudo
Em 1968, Dijkstra publicou uma carta histórica:
👉 “Go To Statement Considered Harmful”
Essa publicação virou um terremoto intelectual na área.
Ele não estava apenas criticando um comando — estava propondo uma nova forma de pensar software.
🧱 O Conceito Central: Programas Devem Ter Estrutura
Structured Programming defende que todo programa pode ser construído usando apenas três estruturas de controle:
1️⃣ Sequência
Executar instruções na ordem.
A
B
C
2️⃣ Seleção (Decisão)
IF condição
A
ELSE
B
END-IF
3️⃣ Iteração (Repetição)
WHILE condição
A
END-WHILE
💡 Só isso. Sem saltos caóticos.
🏗️ O Impacto no Mainframe
 |
| Folha de Codificacao COBOL |
 |
| Terminal 3270 |
 |
| Programa COBOL |
Structured Programming influenciou diretamente:
COBOL moderno (COBOL-74 em diante)
Pascal (projetado para ensino estruturado)
C
Ada
praticamente todas as linguagens posteriores
No COBOL, surgiram práticas como:
PERFORM estruturado
END-IF, END-PERFORM
eliminação de GO TO sempre que possível
💬 Nos ambientes corporativos, isso foi decisivo para sistemas críticos sobreviverem décadas.
☕ Comentário Bellacosa Mainframe
Se você já abriu um programa legado cheio de:
GO TO ERRO-999
GO TO SAIDA
GO TO VOLTA-LOOP
GO TO TRATA-ABEND
Você sabe exatamente por que Dijkstra virou uma lenda 😅
Structured Programming não é frescura acadêmica.
👉 É o que permite um sistema bancário rodar 40 anos sem colapsar.
🕵️ Curiosidades e Bastidores
🧩 1) Dijkstra odiava computadores “bagunçados”
Ele acreditava que programação deveria ser uma disciplina matemática rigorosa.
Chegou a dizer que:
“Testar pode mostrar a presença de bugs, nunca sua ausência.”
✍️ 2) Ele escrevia à mão
Sim — muitos de seus algoritmos eram desenvolvidos no papel antes de qualquer implementação.
🧮 3) Também criou o algoritmo de caminho mínimo
👉 O famoso Algoritmo de Dijkstra, base de roteamento e GPS.
🧨 4) Nem todo mundo gostou da crítica ao GOTO
Programadores da época reagiram com:
indignação
sarcasmo
artigos contra
debates acalorados
Hoje parece óbvio. Na época, foi uma guerra cultural.
🐣 Easter Egg Mainframe
Mesmo em sistemas altamente estruturados…
👉 GO TO nunca morreu completamente.
Em COBOL legado, ele aparece como:
fuga de erro
tratamento de exceções improvisado
controle de fluxo antigo
patches históricos
É o equivalente ao:
“Não encoste nisso que está funcionando.”
🤫 Fofoquice Histórica
Dijkstra não gostava de popularização excessiva da programação.
Ele acreditava que:
👉 nem todos deveriam programar
👉 programação é atividade intelectual profunda
👉 más práticas se espalham rápido demais
Hoje, com milhões de devs no mundo… imagine o que ele diria 😄
🚀 Por que isso ainda importa HOJE?
Structured Programming é a base de:
Clean Code
Arquitetura de Software
Boas práticas corporativas
Programação orientada a objetos
Sistemas críticos
Segurança e confiabilidade
Sem essa revolução, software moderno seria inviável.
✅ Conclusão
Structured Programming não é apenas um capítulo da história.
👉 É o alicerce invisível de praticamente todo software sério já escrito.
No mundo mainframe, especialmente, ela foi a diferença entre:
💀 sistemas incontroláveis
e
🏦 infraestruturas que sustentam economias inteiras
sábado, 10 de julho de 2010
🔥 PERFORM no COBOL: você manda ou ele manda em você?
 |
| Bellacosa Mainframe apresenta o comando Perform em COBOL |
🔥 PERFORM no COBOL: você manda ou ele manda em você?
(Um café no Bellacosa Mainframe, para padawans e cavaleiros Jedi do z/OS)
Você já deu o spoiler certo: PERFORM é o maestro do COBOL.
Quem domina PERFORM escreve código legível, previsível, auditável e aceito em produção.
Quem não domina… acaba criando um GO TO disfarçado com terno e gravata 😅
Vamos organizar, aprofundar e elevar o nível do que você trouxe — com exemplos reais, pegadinhas, DB2, CICS e dicas de campo.
 |
| COBOL e o Perform |
🧠 Origem e filosofia do PERFORM
Nos anos 70, COBOL sofreu com o “spaghetti code” (muito GO TO).
O PERFORM surgiu como a resposta estruturada, permitindo:
-
Modularidade
-
Fluxo previsível
-
Testabilidade
-
Facilidade de manutenção (sim, o auditor agradece)
👉 Regra de ouro mainframe:
“Se dá pra fazer com PERFORM, NÃO use GO TO.”
 |
| Comando Perform e suas variações em COBOL |
📌 O que faz
Executa um parágrafo uma única vez.
🧪 Exemplo real
💡 Dica Bellacosa
-
Sempre crie o
-EXIT -
Facilita debug, tracing e manutenção futura
2️⃣ PERFORM VARYING — o FOR do COBOL
📌 O que faz
Loop com contador explícito.
🧪 Exemplo com tabela interna
⚠️ Pegadinha clássica
❌ Alterar WS-CONT dentro do parágrafo executado
✔️ Deixe o controle só no PERFORM
3️⃣ PERFORM UNTIL — o rei da leitura de arquivos
📌 O que faz
Repete até a condição ser verdadeira
(atenção: condição é avaliada antes)
🧠 Padrão mainframe clássico
-
Batch
-
VSAM
-
Sequential files
-
DB2 cursors (já já)
4️⃣ PERFORM TIMES — simples, direto e elegante
📌 O que faz
Executa um bloco N vezes, sem contador explícito.
📌 Quando usar
-
Simulações
-
Inicializações
-
Processos fixos
❌ Quando NÃO usar
-
Quando você precisa do índice (use VARYING)
5️⃣ PERFORM THRU — tradição mainframe raiz 🧓💾
📌 O que faz
Executa uma sequência contínua de parágrafos
🧪 Estrutura clássica
⚠️ Regra sagrada
Nunca coloque código fora da sequência THRU
Senão…
🔥 comportamento imprevisível
🔥 bugs fantasma
🔥 chamado em produção às 3h da manhã
🟦 PERFORM + DB2 (exemplo real)
Cursor com PERFORM UNTIL
👉 Padrão de ouro DB2 COBOL
🟩 PERFORM + CICS
✔ Modular
✔ Legível
✔ Fácil de testar
🧨 Erros comuns em produção
| Erro | Impacto |
|---|---|
| PERFORM THRU mal delimitado | Execução inesperada |
| Alterar contador no parágrafo | Loop infinito |
| Falta de EXIT | Debug caótico |
| GO TO misturado com PERFORM | Código ilegível |
🧙 Curiosidades & Easter Eggs
🥚 Em COBOL antigo, PERFORM THRU era o padrão absoluto
🥚 Auditores AMAM código com PERFORM bem estruturado
🥚 Muitos shops ainda proíbem GO TO por norma interna
🥚 PERFORM é um dos motivos do COBOL sobreviver tão bem até hoje
🎓 Regra final para padawans
Se você entende PERFORM, você entende o fluxo do COBOL.
Se entende o fluxo, domina Batch, DB2 e CICS.
sexta-feira, 2 de fevereiro de 2007
O que é Paradigma de Programação Procedural Estruturado?
 |
| Bellacosa Mainframe e o paradigma de programacao procedural estruturado |
O que é Paradigma de Programação Procedural Estruturado?
Quando estudamos:
COBOL;
C;
PL/I;
programação batch;
desenvolvimento no mainframe;
um conceito muito importante aparece:
programação procedural estruturada.
Ela foi uma enorme evolução na história da computação corporativa.
Primeiro: o que significa “procedural”?
Programação procedural é:
organizar programas em procedimentos e rotinas.
Exemplo:
VALIDAR
CALCULAR
GERAR-RELATORIO
Cada parte executa:
uma tarefa específica.
Então o que significa “estruturada”?
Estruturada significa:
organizar o código de forma clara, previsível e controlada.
Ela evita:
confusão;
desvios excessivos;
código caótico;
spaghetti code.
Definição simples
Programação procedural estruturada é:
um paradigma procedural que usa estruturas organizadas de fluxo e modularização.
Ela busca:
clareza;
manutenção;
organização;
legibilidade.
Analogia simples
Imagine uma cidade.
Código não estruturado
Ruas sem organização.
Tudo confuso.
Código estruturado
Cidade organizada:
avenidas;
sinais;
setores;
fluxo lógico.
Origem histórica
Nos primeiros sistemas:
Assembly;
COBOL antigo;
FORTRAN antigo;
era comum usar muitos:
GO TO
Isso criava programas extremamente difíceis de manter.
Então surgiu a programação estruturada
Com conceitos como:
blocos;
procedimentos;
loops;
IF;
modularização.
Objetivo principal
Eliminar:
spaghetti code.
O que é spaghetti code?
Código cheio de:
desvios;
GO TO;
saltos;
fluxo confuso.
Parecendo:
um prato de espaguete.
Exemplo não estruturado
GO TO A100
GO TO B200
GO TO C300
Fluxo difícil de entender.
Exemplo estruturado
IF SALDO > 0
PERFORM PROCESSA
ELSE
PERFORM ERRO
END-IF
Muito mais organizado.
Estruturas fundamentais da programação estruturada
Sequência
Execução linear.
Decisão
Escolha de caminhos.
Repetição
Loops controlados.
Fluxo estruturado clássico
INICIO
↓
LER DADOS
↓
VALIDAR
↓
PROCESSAR
↓
GERAR SAÍDA
↓
FIM
Como isso aparece no COBOL?
Muito fortemente.
Exemplo COBOL estruturado
PERFORM UNTIL EOF = 'S'
READ CLIENTE
AT END
MOVE 'S' TO EOF
NOT AT END
PERFORM PROCESSA-CLIENTE
END-READ
END-PERFORM
Isso é estruturado porque:
possui fluxo claro;
evita GO TO;
usa blocos organizados.
O que é modularização?
Dividir programa em partes menores.
Exemplo
VALIDAR-CLIENTE
CALCULAR-JUROS
GERAR-RELATORIO
Benefícios
manutenção;
reutilização;
clareza;
testes mais fáceis.
O que é bloco estruturado?
Código delimitado logicamente.
Exemplos COBOL
IF / END-IF
EVALUATE
PERFORM UNTIL
Antes da programação estruturada
Muito código tinha:
GO TO
em excesso.
Problema disso
Fluxo imprevisível.
Programação estruturada ajudou a:
reduzir bugs;
melhorar manutenção;
aumentar confiabilidade.
O COBOL moderno é estruturado?
Sim.
Principalmente usando:
END-IF;
EVALUATE;
PERFORM;
inline PERFORM.
Exemplo batch estruturado
LER ARQUIVO
↓
VALIDAR
↓
CALCULAR
↓
ATUALIZAR DB2
↓
GERAR RELATÓRIO
Como isso ajuda no mainframe?
Mainframes processam:
milhões;
bilhões de registros.
Precisam de:
estabilidade;
clareza;
manutenção segura.
Programação estruturada trouxe exatamente isso
Características da programação procedural estruturada
Fluxo previsível
Menos GO TO
Uso de procedimentos
Modularização
Blocos organizados
Facilidade manutenção
Legibilidade
Vantagens
Código mais limpo
Mais fácil de entender
Menos erros
Melhor debugging
Excelente para batch
Muito usada em COBOL
Desvantagens
Sistemas gigantes ainda podem ficar complexos
Exige disciplina de programação
Modularização ruim pode dificultar manutenção
Procedural estruturado vs procedural antigo
Antigo
Muito:
GO TO
Estruturado
Mais:
IF
PERFORM
EVALUATE
Procedural estruturado vs orientação a objetos
Estruturado
Organiza:
procedimentos.
OO
Organiza:
objetos/classes.
Curiosidades incríveis
1. A programação estruturada revolucionou o desenvolvimento corporativo
2. Grande parte do COBOL moderno segue princípios estruturados
3. Muitos sistemas bancários antigos passaram por “reestruturação” para remover GO TO
4. Estruturação ajudou muito na manutenção de sistemas gigantes
Erros comuns de iniciantes
1. Usar GO TO demais
2. Criar procedimentos enormes
3. Misturar lógica demais
4. Não modularizar
Dicas importantes
Use:
PERFORM;
IF;
EVALUATE.
Evite GO TO excessivo
Divida lógica em pequenas rotinas
Organize fluxo claramente
Como isso aparece no dia a dia?
Praticamente em:
COBOL;
batch;
DB2 procedural;
faturamento;
bancos;
folha salarial.
Exemplo simplificado completo
MAIN
↓
LER CLIENTES
↓
VALIDAR
↓
CALCULAR
↓
ATUALIZAR DB2
↓
GERAR RELATÓRIO
↓
FIM
Resumo rápido
| Conceito | Significado |
|---|---|
| Procedural | Baseado em procedimentos |
| Estruturado | Fluxo organizado |
| Modularização | Dividir programa |
| PERFORM | Executa rotina |
| IF | Decisão |
| GO TO | Desvio fluxo |
| Spaghetti Code | Código confuso |
Conclusão
O paradigma de programação procedural estruturado organiza programas em procedimentos claros e fluxos previsíveis, reduzindo complexidade e facilitando manutenção.
Ele é a base do COBOL moderno e do processamento batch corporativo no ambiente mainframe IBM Z.
Subscrever:
Mensagens (Atom)
