Seu código de validação de CPF tá gritando por socorro (e...

Deixa eu adivinhar.

Você tá com um projeto Laravel rodando, tem uns 5, 10, talvez 15 formulários que recebem CPF. Cadastro de cliente, cadastro de fornecedor, atualização de perfil, checkout, área administrativa… e em cada um desses lugares tem aquela mesma lógica de validação de CPF. Copiada. Colada. Com pequenas variações.

E tá tudo bem. Até o dia em que o cliente pede pra mudar uma regra. Ou um bug aparece em um formulário e funciona normal no outro. Aí você abre o projeto, dá um Ctrl+Shift+F procurando "cpf" e… surpresa: tem oito lugares diferentes com a mesma validação. Com mensagens de erro escritas de oito jeitos. Uma delas até com erro de digitação.

Já passou por isso? Então senta que essa conversa é pra você.

O crime acontecendo em câmera lenta

Olha esse cenário aqui, que eu garanto que você já viu (ou escreveu):

// app/Http/Requests/StoreClienteRequest.php
public function rules()
{
    return [
        'cpf' => ['required', function ($attribute, $value, $fail) {
            $cpf = preg_replace('/[^0-9]/', '', $value);
            if (strlen($cpf) !== 11) {
                $fail('CPF inválido.');
                return;
            }
            // ... mais 20 linhas do algoritmo
        }],
    ];
}

E aí, três dias depois, no outro Form Request:

// app/Http/Requests/StoreFornecedorRequest.php
public function rules()
{
    return [
        'cpf' => ['required', function ($attribute, $value, $fail) {
            $cpf = preg_replace('/[^0-9]/', '', $value);
            if (strlen($cpf) !== 11) {
                $fail('O CPF informado não é válido!');  // mensagem diferente, claro
                return;
            }
            // ... mais 20 linhas quase iguais, mas não exatamente
        }],
    ];
}

Multiplica isso por 8 telas. Agora imagina o seu "eu do futuro" tentando manter isso.

Dá pra sentir a dor daqui.

DRY: a sigla que vai salvar seu projeto (e sua sanidade)

DRY significa Don't Repeat Yourself. Em bom português: não se repita, caramba.

A ideia é simples: cada pedaço de conhecimento (uma regra de negócio, um cálculo, uma validação) deve existir em um único lugar no seu sistema. Se precisar mudar, você muda em um lugar só, e todo o resto continua funcionando.

No nosso caso, a "regra de validar CPF" é um conhecimento. E esse conhecimento merece ter um endereço fixo no seu projeto, não ficar espalhado igual confete depois do Carnaval.

E se eu te dissesse que o Laravel já resolveu isso pra você?

O Laravel tem um recurso chamado Custom Validation Rule. É basicamente uma classe que encapsula uma regra de validação. Você escreve uma vez, usa em qualquer lugar.

Gera com um comando:

php artisan make:rule Cpf

Isso cria o arquivo app/Rules/Cpf.php. Abre ele e coloca o algoritmo de validação ali dentro:

<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;

class Cpf implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        // Tira tudo que não é número
        $cpf = preg_replace('/[^0-9]/', '', (string) $value);

        // CPF tem 11 dígitos. Ponto.
        if (strlen($cpf) !== 11) {
            $fail('O :attribute informado não é um CPF válido.');
            return;
        }

        // Rejeita sequências repetidas (111.111.111-11, 222.222.222-22, etc)
        if (preg_match('/(\d)\1{10}/', $cpf)) {
            $fail('O :attribute informado não é um CPF válido.');
            return;
        }

        // Calcula os dois dígitos verificadores
        for ($t = 9; $t < 11; $t++) {
            $d = 0;
            for ($c = 0; $c < $t; $c++) {
                $d += $cpf[$c] * (($t + 1) - $c);
            }
            $d = ((10 * $d) % 11) % 10;

            if ($cpf[$c] != $d) {
                $fail('O :attribute informado não é um CPF válido.');
                return;
            }
        }
    }
}

Pronto. Acabou. Esse é o único lugar do seu projeto que sabe validar CPF.

Usando na prática

Agora vem a parte boa. Você usa essa Rule em qualquer lugar, com uma linha:

Em um Form Request:

use App\Rules\Cpf;

public function rules()
{
    return [
        'cpf' => ['required', new Cpf()],
    ];
}

Inline no controller:

$request->validate([
    'cpf' => ['required', new Cpf()],
]);

Com Validator facade:

Validator::make($request->all(), [
    'cpf' => ['required', new Cpf()],
])->validate();

Mesmo código. Mesma mensagem de erro. Mesmo comportamento. Em todo lugar.

Mudou a regra? Mexe no app/Rules/Cpf.php. Pronto, mudou em todo lugar.

Pausa rápida: Rule não é Role

Detalhe que confunde muita gente (e tudo bem, eu também já confundi):

Rule = regra de validação. É disso que a gente tá falando.
Role = papel de usuário, ligado a permissões e autorização (tipo "admin", "editor", "cliente").

São coisas completamente diferentes, só têm nome parecido. Se você buscou no Google "Laravel Role validação" e tava perdido, agora sabe o porquê. 😄

Bônus: e agora?

Pegou a ideia? Então olha quantas outras validações no seu projeto provavelmente tão duplicadas:

CNPJ
Telefone (com DDD, formato brasileiro)
CEP
Data de nascimento (maioridade, idade mínima, etc)
Placa de veículo
Cartão de crédito

Cada uma dessas é uma Rule esperando pra nascer. Que tal escolher uma e criar agora? Lição de casa rápida pra quando você terminar de ler isso aqui.

Antes de você fechar a aba

Aqui vai uma pergunta sincera: qual validação você ainda mantém copiada e colada no seu projeto Laravel?

Comenta aí embaixo. Eu juro que não vou julgar (eu mesmo tenho um projeto antigo que precisa urgentemente desse refactor).

E se esse post te poupou de uma dor de cabeça futura, salva ele, compartilha com aquele dev que tá começando agora, ou manda pro seu colega de equipe que tá com 14 controllers validando CPF do jeito errado.

Seu eu do futuro agradece. Seu projeto, também.

Curtiu? Tem mais conteúdo sobre Laravel, boas práticas e como deixar seu código mais limpo por aqui. Me segue pra não perder os próximos.

推荐订阅源

DEV Community