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

# Les 20 motifs Regex que j'utilise réellement (Après avoir supprimé massivement les 200 autres)

Un jour, j'ai écrit un regex de 847 caractères pour la validation des e-mails. Cela m'a coûté trois heures de ma vie que je ne retrouverai jamais, avec des lookaheads imbriqués, des exceptions de classes de caractères, et assez de barres obliques inverses pour me faire pleurer les yeux. J'en étais si fier. Je l'ai posté sur notre Slack d'équipe avec un message satisfait "Cela gère TOUS les cas extrêmes".

Ensuite, quelqu'un m'a lié à la RFC 5322.

Pour ceux qui ne le savent pas, la RFC 5322 est la spécification officielle des adresses e-mail. Le motif regex complet et réel qui valide chaque adresse e-mail techniquement légale fait plus de 6 000 caractères. Elle inclut des choses comme des commentaires entre parenthèses, des chaînes citées avec des caractères échappés, et des littéraux de domaine entre crochets. Techniquement, `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` est une adresse e-mail valide selon la spécification.

J'ai fixé mon regard sur mon motif de 847 caractères. Puis sur la RFC. Puis de nouveau sur mon motif. Ensuite, j'ai fait ce que ferait tout développeur raisonnable : je l'ai remplacé par `/.+@.+\..+/` et j'ai continué ma vie. Parce que — personne n'utilise réellement ces cas extrêmes. Et s'ils le font, ils méritent ce qui casse.

C'était il y a cinq ans. Depuis, j'ai écrit des centaines de motifs regex. J'ai débogué des regex qui ont fait pleurer des développeurs seniors. J'ai optimisé des motifs qui causaient des ralentissements en production. Et à travers tout cela, j'ai appris quelque chose de crucial : la plupart des motifs regex sont des déchets dont vous n'aurez jamais besoin.

Mon voyage d'un maximaliste du regex à un minimaliste

Je collectionnais autrefois des motifs regex comme certaines personnes collectionnent des timbres. J'avais un immense fichier `regex-library.js` avec des motifs pour tout ce qui est imaginable. Adresses IPv6 avec ID de zone. Numéros de carte de crédit avec validation de l'algorithme de Luhn. URLs qui prenaient en charge tous les protocoles obscurs. Numéros de sécurité sociale avec validation des codes de zones des années 1930.

Le fichier faisait 3 200 lignes. J'étais convaincu que je construisais quelque chose de précieux—une bibliothèque complète qui me ferait gagner du temps sur chaque projet. J'avais même commencé à écrire la documentation, avec des exemples et des benchmarks de performance.

Ensuite, j'ai changé d'emploi.

Dans ma nouvelle entreprise, j'ai essayé d'importer ma précieuse bibliothèque regex dans notre code. L'architecte senior a jeté un coup d'œil et a posé une question simple : "Lequel de ces motifs as-tu réellement utilisé au cours des six derniers mois ?"

J'ai passé le fichier avec un surligneur. Sur plus de 200 motifs, j'en avais utilisé peut-être 15. Le reste était des motifs "juste au cas où" — des solutions à la recherche de problèmes. Des motifs que j'avais écrits parce qu'ils étaient intellectuellement intéressants, pas parce qu'ils résolvaient de réels problèmes.

C'est alors que j'ai commencé ma grande purge de regex. J'ai parcouru chaque motif et demandé : "En ai-je eu besoin en production ? Pas 'pourrais-je en avoir besoin un jour', mais en ai-je réellement eu besoin ?" Si la réponse était non, il était supprimé. Pas de pitié. Pas d'exceptions "mais que se passe-t-il si".

Le fichier est passé de 3 200 lignes à 400. Puis à 200. Puis à environ 100 lignes contenant 20 motifs que j'utilise réellement régulièrement. Et vous savez quoi ? Je n'ai jamais regretté les autres 180 motifs. Pas même un peu.

Cette fois où le regex a failli faire tomber notre API

Permettez-moi de vous parler de l'incident de production le plus grave que j'ai jamais causé avec le regex. Nous avions un point de terminaison API qui acceptait du contenu généré par les utilisateurs—essentiellement un champ de notes où les utilisateurs pouvaient écrire ce qu'ils voulaient. Assez simple, non ?

Sauf que nous voulions détecter et auto-lier les URLs dans le texte. J'ai donc écrit ce que je croyais être un motif regex intelligent qui correspondrait aux URLs tout en évitant les faux positifs. Il contenait des lookaheads pour vérifier la validité des protocoles, des classes de caractères pour les noms de domaine, des numéros de port optionnels, des segments de chemin, des paramètres de requête et des identifiants de fragment. C'était magnifique. C'était complet. C'était une erreur catastrophique.

Le motif fonctionnait bien dans les tests. J'y ai lancé diverses URLs, et il les a traitées parfaitement. Je me sentais plutôt bien quand nous avons déployé en production un vendredi après-midi. (Oui, je sais. Ne jamais déployer un vendredi. J'ai appris cette leçon à mes dépens.)

En moins d'une heure, nos temps de réponse API sont passés de 50 ms à 30 secondes. Puis les délais d'attente ont commencé à se produire. Notre surveillance s'est allumée comme un sapin de Noël. Les utilisateurs se plaignaient. Mon téléphone sonnait. C'était mauvais.

Le coupable ? Un utilisateur avait collé une longue chaîne de texte qui contenait des motifs déclenchant un backtracking catastrophique dans mon regex. Le moteur regex essayait chaque combinaison possible de correspondances, et avec une chaîne d'entrée de 5 000 caractères, cela signifiait des milliards de tentatives. Chaque requête saturait un cœur de CPU à 100 % pendant plus de 30 secondes avant de provoquer un délai d'attente.

Nous avons immédiatement annulé le déploiement, et j'ai passé le week-end à réécrire ce motif. La nouvelle version était plus simple, moins "intelligente", et avait des limites explicites sur la répétition. Elle ne capturait pas tous les formats d'URL possibles—elle capturait 99,9 % des URLs que les gens utilisent réellement. Et elle s'exécutait en microsecondes au lieu de secondes.

Cet incident m'a appris quelque chose de crucial : la complexité des regex est une responsabilité, pas un atout. Plus votre motif est sophistiqué, plus il est probable qu'il vous cause des problèmes en production. Des motifs simples qui gèrent des cas courants sont presque toujours meilleurs que des motifs complexes qui gèrent chaque cas extrême.

Décomposer ce qui compte vraiment

Après des années à écrire des regex et à apprendre de mes erreurs, j'ai développé un cadre simple pour décider quels motifs valent la peine d'être conservés. Cela se résume à trois critères :

En utilisant ces critères, la plupart des motifs ne passent pas. Ce regex sophistiqué pour analyser les dates ISO 8601 avec décalages de fuseau horaire et numéros de semaine ? Échoue au test de fréquence—j'en ai besoin peut-être deux fois par an, et quand j'en ai besoin, je peux le rechercher. Le motif pour valider les numéros de comptes bancaires IBAN ? Échoue au test de fiabilité—il est si complexe que je ne me fais pas confiance pour le maintenir. Le motif récursif pour faire correspondre les parenthèses imbriquées ? Échoue au test de performance—c'est un cauchemar de backtracking qui attend d'arriver.

Ce qui reste ce sont des motifs qui sont simples, rapides et résolvent des problèmes que je rencontre régulièrement. Ce ne sont pas les motifs les plus intéressants. Ce ne sont pas ceux qui vous donnent l'impression d'être intelligent. Mais ce sont ceux qui comptent réellement.

Le meilleur motif regex est celui que vous pouvez comprendre six mois plus tard à 2h du matin lorsque la production est en panne et que vous essayez de comprendre pourquoi l'entrée utilisateur casse votre validation.

Les 20 motifs qui ont survécu à la purge

Voici la liste complète des motifs regex que j'utilise réellement, organisée par catégorie. Ce sont les survivants—les motifs qui ont prouvé leur valeur par une utilisation répétée dans de vrais projets.