Foi lançado recentemente a terceira edição do livro “Expressões Regulares – Uma abordagem divertida” do autor Aurélio Marinho Jargas. Tive a oportunidade de conhecê-lo pessoalmente no lançamento e ainda ganhar um livro gratuito por ter sido sorteado na promoção do Twitter, aliás, é a primeira vez que eu ganho algo no Twitter :)

Sobre o Livro

#piazinho3

Eu já havia lido a edição anterior, e esta nova edição ficou bem parecida, continua seguindo o que o título propõe: Ser uma abordagem divertida. Você consegue ler o core dele em uma viajem de avião ou em algumas corridas de ônibus de ida e volta da faculdade. Eu defino o core do livro como sendo aquilo que você usa independente do lugar, linguagem ou ferramenta. Seriam os primeiros capítulos onde ele fala dos metacaracteres e suas combinações.

Achei bem bacana a novidade que ele traz no início do livro, pelo menos eu não lembro ter lido isso na edição anterior. O Aurélio conta como foi sua trajetória durante todas as publicação de seus livros. Cara, como um programador/pesquisador vira fotógrafo de surfe? Inacreditável, seria uma das últimas profissões que passaria em minha mente.

Confesso que depois de ler deu vontade de escrever um livro, quem sabe não sai algo nos próximos anos?

Bom, meu objetivo com o post não é falar do livro em si, e sim de boas práticas com Expressões Regulares. Não irei explicar o que é, como funciona ou como fazer uma ER para casar com isso ou aquilo. Vou considerar que você já tenha uma noção, até mesmo básica, de Expressões Regulares. Não sabe? Compre o livro :)

Práticas que recomendo com Expressões Regulares

Enumerei quatro itens que acho pertinente ao assunto, que são os seguintes.

1) Violação do princípio da responsabilidade exclusiva (SRP)

É preciso tomar cuidado com o local onde você coloca os casamentos de suas expressões regulares. Se for inserir a expressão dentro de um método cuja a responsabilidade não seja validar a entrada com base na expressão, você estará atropelando o Single Responsibility Principle, defendido pelo Guru Uncle Bob (mais detalhes sobre o SRP você encontra aqui).

Validar a entrada contra uma expressão regular já uma responsabilidade e não deve ser misturada com outras, separe as responsabilidades em classes distintas, facilita a manutenção, o design estará de acordo com o SRP e ajudará no item 2 desta lista.

2) Comentários de exemplos

Sou contra o uso de comentários, sou da opinião de que se você precisa comentar é porque está dificil de entender. Ora, se está dificil de entender, arrume e não comente. Nada pior do que ver 5 linhas de código e 20 de comentário. Se estiver com dificuldades para tornar o código mais limpo, sugiro que dê uma olhada no livro Clean Code do Uncle Bob.

Depois de expressar meu motivo pela qual sou contra o uso de comentários, preciso dizer que, como tudo na vida, existem exceções. Nas Expressões Regulares por exemplo, é muito útil informar com o que aquele pattern vai casar, com e-mails? sites? telefones?

Colocar exemplos de entradas que casam e que não casam também ajuda bastante na leitura. Veja como ficaria um exemplo em C#.

// Pattern para verificar o formato de e-mail.
//
// Exemplos válidos
// - joazinho@piadas.com.br, maria@algumsite.com.br
// Exemplos inválidos
// - joazinhopiadas.com.br, maria@algumsite
string emailPattern = @"^[\w-]+(\.[\w-]+)*@([a-z0-9-]+(\.[a-z0-9-]+)*?\.[a-z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$";

3) Quanto mais legível, melhor

Esta dica está no livro, tamanho não é documento, cuidado com expressões gigantes e com aquelas minúsculas, procure sempre fazer um pattern legível.

As vezes é difícil deixar essa sopa de letrinhas de modo organizado, um exemplo legal é este do e-mail logo acima. Você consegue entender? É difícil né? Ainda bem que há comentários.

4) Procure alternativas

Tenha certeza que existem N maneiras de resolver um problema, expressões regulares são ótimas mas não são as balas de prata. Não complique, conheça seu framework, procure a melhor solução. Para validação no input de dados preciso concordar que as expressão resolvem com bastante facilidade, mas para descobrir se um caracter é um número ou não, em C# você pode usar o char.IsDigit(). Muito mais elegante, concorda?

Se você não possui um equivalente em sua linguagem preferida, crie. Mas não esqueça de separar ela em outra classe, comentar e deixar legível :)