Les expressions régulières sont un outil puissant dans l'arsenal du programmeur, mais il existe des cas où elles ne constituent pas le meilleur choix, voire qu'elles sont totalement nuisibles.

L'exemple simple n ° 1 consiste à analyser HTML avec regexp - une route connue pour de nombreux bogues. Cela est probablement dû également à l' analyse en général.

Mais, y a-t-il d'autres zones clairement interdites pour les expressions régulières?

ps: " La question que vous posez a un caractère subjectif et est susceptible d'être fermée. "

N'utilisez pas d'expressions régulières:

• Quand il y a des parseurs.

Cela ne se limite pas à HTML . Un simple XML valide ne peut pas être raisonnablement analysé avec une expression régulière, même si vous connaissez le schéma et savez qu'il ne changera jamais.

N'essayez pas, par exemple, d' analyser le code source C # . Au lieu de cela, analysez-le pour obtenir une arborescence significative ou les jetons.

• Plus généralement, lorsque vous avez de meilleurs outils pour faire votre travail.

Que faire si vous devez rechercher une lettre, petite ou capitale? Si vous aimez les expressions régulières, vous les utiliserez. Mais n'est-il pas plus facile / plus rapide / lisible d'utiliser deux recherches l'une après l'autre? Il est probable que dans la plupart des langues, vous obtiendrez de meilleures performances et que votre code soit plus lisible.

Par exemple, l'exemple de code dans la réponse d'Ingo est un bon exemple dans lequel vous ne devez pas utiliser d'expressions régulières. Il suffit de chercher foo, puis de bar.

• Lors de l'analyse de l'écriture humaine.

Un bon exemple est un filtre d'obscénité. Non seulement c'est une mauvaise idée de l'implémenter en général, mais vous pouvez être tenté de le faire en utilisant des expressions régulières et vous le ferez mal. Un humain peut écrire un mot, un nombre, une phrase de différentes manières et sera compris par un autre humain, mais pas par votre expression habituelle. Ainsi, au lieu d’attraper une véritable obscénité, votre expression habituelle passera son temps à faire mal aux autres utilisateurs.

• Lors de la validation de certains types de données.

Par exemple, ne validez pas une adresse électronique à l'aide d'une expression régulière. Dans la plupart des cas, vous le ferez mal. Dans de rares cas, vous le ferez bien et vous terminerez avec une horreur de 6 343 caractères .

• Lorsque vous n'avez pas les bons outils ou ne vous souciez pas du code propre.

Sans les bons outils, vous ferez des erreurs. Et vous les remarquerez au dernier moment, ou peut-être jamais. Si vous ne vous souciez pas du code propre, vous écrirez une chaîne de vingt lignes sans commentaires, sans espaces, sans nouvelles lignes.

• Quand votre code sera lu. Et ensuite, relisez, et encore et encore, à chaque fois par différents développeurs.

Sérieusement, si je prends votre code et que je dois le réviser ou le modifier, je ne veux pas passer une semaine à essayer de comprendre une chaîne de vingt lignes contenant beaucoup de symboles.

Le plus important: lorsque le langage que vous analysez n’est pas un langage courant .

Le langage HTML n’est pas un langage courant et il n’est pas possible de l’ analyser avec une expression régulière (ce n’est pas seulement difficile ou c’est une route menant au code buggy).

Sur stackoverflow, on voit souvent des personnes demander des expressions rationnelles qui déterminent si une chaîne donnée ne contient pas ceci ou cela. C'est, à mon humble avis, inverser le but de l'expression régulière. Même s'il existe une solution (en utilisant des assertions de regard négatives derrière soi ou ce genre de choses), il est souvent préférable d'utiliser l'expression régulière pour son but et de gérer le cas négatif avec la logique de programme.

Exemple:

# bad
if (/complicated regex that assures the string does NOT conatin foo|bar/) {
    # do something
}

# appropriate
if (/foo|bar/) {
    # error handling
} else {
    # do something
}

Deux cas:

Quand il y a un moyen plus facile

• La plupart des langages fournissent une fonction simple comme INSTR pour déterminer si une chaîne est un sous-ensemble d'une autre. Si c'est ce que vous voulez faire, utilisez la fonction la plus simple. N'écris pas ta propre expression régulière.

• Si une bibliothèque est disponible pour effectuer une manipulation de chaîne complexe, utilisez-la plutôt que d'écrire votre propre expression régulière.

Lorsque les expressions régulières ne sont pas suffisamment puissantes

• Si vous avez besoin d'un analyseur, utilisez un analyseur.

Les expressions régulières ne peuvent pas identifier les structures récursives . C'est la limitation fondamentale.

Prenez JSON - c'est un format assez simple, mais comme un objet peut contenir d'autres objets en tant que valeurs membres (arbitrairement profondes), la syntaxe est récursive et ne peut pas être analysée par une expression régulière. D'autre part, CSV peut être analysé par regex'es puisqu'il ne contient aucune structure récursive.

En bref, les expressions régulières ne permettent pas au motif de se référer à lui-même. Vous ne pouvez pas dire: à ce stade de la syntaxe, associez à nouveau l'ensemble du modèle. En d'autres termes, les expressions régulières ne correspondent que de manière linéaire, elle ne contient pas de pile qui lui permettrait de garder une trace de la profondeur à laquelle se trouve un modèle imbriqué.

Notez que cela n’a rien à voir avec la complexité ou la complexité du format. Les expressions S sont vraiment très simples, mais ne peuvent pas être analysées avec une expression régulière. CSS2, en revanche, est un langage assez complexe, mais ne contient pas de structures récursives et peut donc être analysé avec une expression régulière. (Bien que cela ne soit pas vrai pour CSS3 en raison des expressions CSS, qui ont une syntaxe récursive.)

Ce n’est donc pas parce qu’il est laid, complexe ou sujet aux erreurs d’analyser HTML en utilisant uniquement regex. C'est que ce n'est tout simplement pas possible .

Si vous devez analyser un format contenant des structures récursives, vous devez au moins compléter l'utilisation d'expressions régulières avec une pile pour garder une trace du niveau des structures récursives. C'est typiquement comment un analyseur fonctionne. Les expressions régulières sont utilisées pour reconnaître les parties "linéaires", tandis que le code personnalisé en dehors de l'expression rationnelle est utilisé pour suivre les structures imbriquées.

Généralement, l'analyse de ce type est divisée en phases distinctes. La tokénisation est la première phase où les expressions régulières sont utilisées pour scinder l'entrée en une séquence de "jetons" tels que des mots, des signes de ponctuation, des crochets, etc. L'analyse est la phase suivante où ces jetons sont analysés dans une structure hiérarchique, un arbre de syntaxe.

Ainsi, lorsque vous entendrez que HTML ou C # ne peuvent pas être analysés par des expressions rationnelles, sachez que celles-ci font toujours partie intégrante des analyseurs. Vous ne pouvez pas analyser un tel langage en utilisant uniquement des expressions régulières et aucun code d'assistance.