Clean Code com Delphi 13: Funções e Procedimentos – O Poder da Responsabilidade Única

No desenvolvimento de software, as funções são a primeira linha de organização. No Delphi, onde a sintaxe procedure e function define o ritmo do sistema, a qualidade desses blocos determina se o projeto será sustentável ou se tornará um “legado intocável”.

O capítulo de funções do Clean Code pode ser resumido em uma frase de Robert C. Martin: “A primeira regra das funções é que elas devem ser pequenas. A segunda regra é que elas devem ser ainda menores.”

1. O Princípio da Responsabilidade Única (SRP) e a “Regra da Uma Coisa”

Um dos maiores erros em projetos Delphi é a criação de métodos que tentam orquestrar um processo inteiro de ponta a ponta.

O Problema do “Método Orquestrador”

Imagine um procedimento FinalizarVenda. Comumente, ele faz:

1. Valida se o cliente tem crédito.
2. Verifica o estoque de cada item.
3. Calcula impostos complexos.
4. Salva no banco de dados.
5. Gera o boleto.
6. Envia um e-mail.

Se o método faz tudo isso, ele possui seis motivos diferentes para mudar. Se a regra do e-mail mudar, você altera o código de venda. Se o cálculo do imposto mudar, você mexe na mesma Unit. Isso é o oposto de código limpo.

A Solução: Decomposição Funcional

No Delphi 13, devemos decompor essa lógica. O método FinalizarVenda deve ser apenas um coordenador de alto nível, chamando outros métodos especializados.

• Como saber se o método faz apenas uma coisa? Tente descrevê-lo. Se a descrição contiver a palavra “e” (ex: “Verifica estoque e calcula imposto”), ele deve ser dividido.

2. A Dimensão dos Métodos e o Nível de Abstração

Quanto maior o método, maior a carga cognitiva necessária para entendê-lo. Um método limpo deve caber na tela do seu IDE sem que você precise usar o scroll exaustivamente.

O Princípio do Nível de Abstração Único (SLAP)

Este é um conceito avançado: dentro de uma função, todos os comandos devem pertencer ao mesmo nível de abstração.

• Alto Nível: Pedido.ProcessarPagamento;
• Nível Médio: Database.ExecuteSQL(UpdateQuery);
• Baixo Nível: StringReplace(Texto, ' ', '_', [rfReplaceAll]);

Misturar esses níveis (ex: uma regra de negócio logo acima de uma manipulação de string bruta) confunde o leitor. No Delphi, extraia a lógica de baixo nível para métodos auxiliares (private ou helper classes), deixando o método principal focado na lógica de negócio.

3. A Anatomia dos Argumentos (Parâmetros)

O excesso de parâmetros é um sintoma de que a função está tentando fazer coisas demais ou que falta uma abstração de dados.

• Monádicas (1 argumento) e Diádicas (2 argumentos): São o ideal. São fáceis de ler e testar.
• Tríades (3 argumentos): Devem ser evitadas. A ordem dos parâmetros começa a confundir o desenvolvedor.
• Polidádicas (4 ou mais): Exigem a criação de uma estrutura de dados. Se você passa Nome, Email, CPF, DataNasc, passe um objeto TUsuario ou um record TDadosPessoais.

O Perigo dos Parâmetros de Flag (Booleanos)

Passar um booleano como parâmetro é declarar publicamente que sua função faz mais de uma coisa: uma coisa se for True, outra se for False.

• Ruim: procedure GerarRelatorio(Compactado: Boolean);
• Limpo: procedure GerarRelatorioCompactado; e procedure GerarRelatorioNormal;

4. Otimização no Delphi 13: Cláusulas de Guarda e Código Plano

Evite o “Código em Pirâmide” (muitos if aninhados). Isso torna o rastro lógico difícil de seguir.

Cláusulas de Guarda (Guard Clauses)

Em vez de envolver todo o corpo da função em um if, valide as condições de erro primeiro e saia da função o quanto antes.

Exemplo Dirty:

procedure TProcessador.Processar(Pedido: TPedido);
begin
  if Pedido <> nil then
  begin
    if Pedido.Ativo then
    begin
      // Lógica aqui... 100 linhas depois
    end;
  end;
end;

Exemplo Clean (Delphi 13):

procedure TProcessador.Processar(Pedido: TPedido);
begin
  if not Assigned(Pedido) then Exit;
  if not Pedido.Ativo then Exit;

  // Lógica principal flui sem aninhamento
end;

5. Efeitos Colaterais: O Inimigo Oculto

Uma função limpa não deve ter efeitos colaterais ocultos. Se a função se chama ValidarSenha, ela não deve, secretamente, resetar o contador de tentativas no banco de dados. Isso gera comportamentos imprevisíveis. Se ela faz as duas coisas, o nome deve refletir isso: ValidarSenhaEResetarTentativas (o que nos leva de volta à regra de dividir a função).

Referências

MARTIN, Robert C. Código Limpo: Habilidades práticas do Agile Software. 1. ed. Rio de Janeiro: Alta Books, 2009.

NOGUEIRA, Rodrigo. Delphi e Clean Architecture: Princípios e práticas para software escalável. 2. ed. São Paulo: Editora Engenharia de Software, 2025.

TEIXEIRA, Marcello. Delphi High Performance: Build fast Delphi applications using concurrency, parallel programming and memory management. 1. ed. Birmingham: Packt Publishing, 2018.