As expressões regulares têm fama de crípticas, mas 90 % do uso real resume-se a um punhado de padrões que se repetem em qualquer projeto: validar um email, extrair um URL, limpar espaços duplicados. O resto é procurar no Google quando aparece o caso raro.
Testa antes de publicar em produção
Antes de meteres uma regex no teu código, testa-a contra vários casos reais — incluindo os que não deveriam corresponder — no testador de expressões regulares. Ele realça cada correspondência e os grupos capturados, para veres logo se o padrão é demasiado permissivo ou demasiado rígido.
Os padrões que vais usar sempre
- Email (validação básica):
^[^\s@]+@[^\s@]+\.[^\s@]+$— não cobre 100 % do RFC, mas chega para formulários. - Só dígitos:
^\d+$ - Espaços duplicados:
\s{2,}— útil para limpar texto colado de um PDF ou Word. - URL com protocolo:
^https?:\/\/[^\s]+$ - Data ISO (AAAA-MM-DD):
^\d{4}-\d{2}-\d{2}$ - Slug (minúsculas e hífenes):
^[a-z0-9]+(-[a-z0-9]+)*$
Os erros mais comuns
- Esquecer de fazer escape ao ponto.
.significa "qualquer caractere", não um ponto literal. Para um domínio, é\.e não. - Ganância por defeito.
<.+>sobre<b>negrito</b>captura desde o primeiro<até ao último>, não apenas uma tag. Usa o quantificador preguiçoso<.+?>para parares no primeiro fecho. - Não ancorar o padrão. Sem
^e$, a tua regex pode corresponder apenas a parte da string e deixar passar lixo antes ou depois. - Confundir
[abc]com(abc). O primeiro significa "uma destas três letras"; o segundo, "a sequência exata abc" como grupo.
Grupos com nome, o teu melhor amigo
Quando extrais vários valores de uma string (partes de um URL, uma data), usa grupos com nome em vez de os contares por posição: (?<ano>\d{4})-(?<mes>\d{2})-(?<dia>\d{2}). O código que consome o resultado torna-se muito mais legível do que match[1], match[2], match[3].
Resumindo: escreve o padrão, testa-o contra casos-limite reais, e só depois o colas no código.