The 20 Regex Patterns I Actually Use (After Mass-Deleting the Other 200)

# Os 20 Padrões Regex Que Eu Realmente Uso (Depois de Deletar em Massa os Outros 200)

Certa vez escrevi um regex de 847 caracteres para validação de e-mail. Isso tomou três horas da minha vida que nunca mais vou recuperar, com lookaheads aninhados, exceções de classes de caracteres e o suficiente de barras invertidas para fazer meus olhos lacrimejarem. Eu estava tão orgulhoso disso. Postei no nosso Slack da equipe com uma mensagem arrogante: "Isso lida com TODOS os casos extremos".

Então alguém me enviou o link da RFC 5322.

Para aqueles que estão alheios, a RFC 5322 é a especificação oficial de endereço de e-mail. O padrão de regex real e completo que valida cada endereço de e-mail tecnicamente legal tem mais de 6.000 caracteres de comprimento. Ele inclui coisas como comentários entre parênteses, strings entre aspas com caracteres de escape e literais de domínio entre colchetes. Tecnicamente, `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` é um endereço de e-mail válido de acordo com a especificação.

Eu olhei para meu padrão de 847 caracteres. Então para a RFC. Depois volta para meu padrão. Então fiz o que qualquer desenvolvedor razoável faria: substituí por `/.+@.+\..+/` e segui em frente com minha vida. Porque — ninguém realmente usa aqueles casos extremos. E se usarem, eles merecem o que quebrar.

Isso foi há cinco anos. Desde então, escrevi centenas de padrões de regex. Eu debuguei regex que fez desenvolvedores seniores chorarem. Otimizei padrões que estavam causando lentidão em produção. E através de tudo isso, aprendi algo crucial: a maioria dos padrões de regex é um lixo que você nunca vai precisar.

Minha Jornada de Maximalista de Regex para Minimalista

Eu costumava colecionar padrões de regex como algumas pessoas colecionam selos. Eu tinha um enorme arquivo `regex-library.js` com padrões para tudo que você puder imaginar. Endereços IPv6 com IDs de zona. Números de cartão de crédito com validação do algoritmo de Luhn. URLs que lidavam com todo protocolo obscuro. Números de seguridade social com validação de código de área da década de 1930.

O arquivo tinha 3.200 linhas. Eu estava convencido de que estava construindo algo valioso — uma biblioteca abrangente que me economizaria tempo em cada projeto. Eu até comecei a escrever documentação para isso, completa com exemplos e benchmarks de desempenho.

Então eu troquei de emprego.

Na minha nova empresa, tentei importar minha amada biblioteca de regex para nossa base de código. O arquiteto sênior deu uma olhada e fez uma pergunta simples: "Quais destes você realmente usou nos últimos seis meses?"

Eu passei pelo arquivo com um marcador. Das mais de 200 análises, eu usei talvez 15. O resto eram padrões "apenas para o caso" — soluções procurando problemas. Padrões que escrevi porque eram intelectualmente interessantes, não porque resolviam questões reais.

Foi então que comecei minha grande limpeza de regex. Passei por cada padrão e perguntei: "Eu precisei disso em produção? Não 'pode ser que eu precise algum dia', mas, eu realmente precisei?" Se a resposta fosse não, ele era deletado. Sem misericórdia. Sem exceções de "mas e se".

O arquivo passou de 3.200 linhas para 400. Depois para 200. Então para cerca de 100 linhas contendo 20 padrões que eu realmente uso regularmente. E sabe de uma coisa? Eu nunca senti falta dos outros 180 padrões. Nem um pouquinho.

Aquele Momento em Que o Regex Quase Derrubou Nossa API

Deixe-me contar sobre o pior incidente de produção que já causei com regex. Tivemos um endpoint de API que aceitava conteúdo gerado pelo usuário — basicamente um campo de notas onde os usuários podiam escrever o que quisessem. Simples, certo?

Exceto que queríamos detectar e auto-vincular URLs no texto. Então eu escrevi o que achava ser um padrão de regex esperto que corresponderia às URLs enquanto evitava falsos positivos. Ele tinha lookaheads para verificar protocolos válidos, classes de caracteres para nomes de domínio, números de porta opcionais, segmentos de caminho, parâmetros de consulta e identificadores de fragmento. Era bonito. Era abrangente. Foi um erro catastrófico.

O padrão funcionou bem nos testes. Joguei várias URLs e ele lidou com elas perfeitamente. Eu estava me sentindo bem quando fizemos o deploy para produção numa tarde de sexta-feira. (Sim, eu sei. Nunca faça deploy numa sexta-feira. Aprendi essa lição da maneira mais difícil.)

Dentro de uma hora, nossos tempos de resposta da API foram de 50ms para 30 segundos. Então começaram os timeouts. Nossa monitoria acendeu como uma árvore de Natal. Os usuários estavam reclamando. Meu telefone estava tocando. Estava ruim.

O culpado? Um usuário colou uma longa string de texto que acontecia de conter padrões que desencadearam retrocesso catastrófico no meu regex. O motor regex estava tentando todas as combinações possíveis de correspondências e, com uma string de entrada de 5.000 caracteres, isso significava bilhões de tentativas. Cada solicitação estava utilizando um núcleo de CPU a 100% por mais de 30 segundos antes de timeouts.

Retornamos imediatamente, e eu passei o fim de semana reescrevendo aquele padrão. A nova versão era mais simples, menos "esperta", e tinha limites explícitos para repetição. Não pegou todos os formatos de URL possíveis—pegou 99,9% das URLs que as pessoas realmente usam. E rodou em microssegundos em vez de segundos.

Esse incidente me ensinou algo crucial: a complexidade do regex é uma responsabilidade, não um ativo. Quanto mais elaborado seu padrão, maior a probabilidade de ele te prejudicar em produção. Padrões simples que lidam com casos comuns são quase sempre melhores do que padrões complexos que lidam com cada caso extremo.

Analisando o que Realmente Importa

Após anos escrevendo regex e aprendendo com meus erros, desenvolvi um quadro simples para decidir quais padrões valem a pena manter. Tudo se resume a três critérios:

Usando esses critérios, a maioria dos padrões não passa. Aquele regex sofisticado para analisar datas ISO 8601 com deslocamentos de fuso horário e números de semana? Não passa no teste de frequência—eu preciso dele talvez duas vezes por ano, e quando preciso, posso procurá-lo. O padrão para validar números de contas bancárias IBAN? Não passa no teste de confiabilidade—é tão complexo que não confio em mim mesmo para mantê-lo. O padrão recursivo para corresponder a parênteses aninhados? Não passa no teste de desempenho—é um pesadelo de retrocesso esperando para acontecer.

O que resta são padrões que são simples, rápidos e resolvem problemas que encontro regularmente. Eles não são os padrões mais interessantes. Não são os que fazem você se sentir inteligente. Mas são os que realmente importam.

O melhor padrão regex é aquele que você pode entender seis meses depois, às 2 da manhã, quando a produção está fora do ar e você está tentando descobrir por que a entrada do usuário está quebrando sua validação.

Os 20 Padrões Que Sobreviveram à Limpeza

Aqui está a lista completa de padrões de regex que eu realmente uso, organizados por categoria. Estes são os sobreviventes—os padrões que provaram seu valor através de uso repetido em projetos reais.