Pourquoi les expressions régulières sont-elles si morbides?

Pièce 1 , pièce 2 , je suppose que vous n'aurez pas de mal à vous souvenir d'autres exemples.

La chose est la suivante: s'il y a plus d'une façon de résoudre un problème, le programmeur PHP (je parcours généralement la balise PHP sur StackOverflow) demandera de l'aide sur la solution impliquant des expressions régulières.

Même quand cela sera moins économique, même lorsque le manuel php suggère ( lien ) d'utiliser à la str_replaceplace de any preg_*ou de ereg_*fonctionner quand aucune règle de substitution sophistiquée n'est requise.

Quelqu'un sait-il pourquoi cela se produit?

Ne vous méprenez pas, certains de mes meilleurs amis sont des expressions régulières et je ne méprise pas Perl. Ce que je ne comprends pas, c'est pourquoi il n'y a aucune recherche d'alternatives, même lorsque la surpuissance est évidente (regex pour changer de chaîne) ou que la complexité du code augmente de façon exponentielle (regex pour obtenir des données html en PHP )

Pourquoi les expressions régulières sont-elles si morbides?

Parce qu'au niveau subconscient, ils se sentent comme un programme intelligent complet qui peut accomplir beaucoup de choses de son propre chef tout en étant englobant et auto-adaptatif (schémas de réflexion).

C'est pourquoi les gens croient immédiatement que les expressions régulières résoudront n'importe quelle tâche basée sur du texte, ne pensant pas que cela pourrait être excessif et ne réalisant pas que cela pourrait me sous-estimer (analyser les langues avec).

Une toute petite chose contenant du pouvoir magique. Vous ne pouvez pas dire non, n'est-ce pas?

Lorsque le seul outil dont vous disposez est une expression régulière, chaque problème ressemble à ^((?>[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+)+|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$

Je pense que c'est parce que:

1. Ils sont incroyablement concis (lorsqu'ils sont utilisés correctement) par rapport au code équivalent, et
2. Ils sont largement pris en charge dans tous les langages de programmation, de sorte que la plupart des développeurs les connaissent.

Dans les phases précédentes de ma carrière (c'est-à-dire pré-PHP), j'étais un gourou de Perl, et un aspect majeur de Perl gurudom est la maîtrise des expressions régulières.

Dans mon équipe actuelle, je suis littéralement le seul d'entre nous à atteindre l'expression régulière avant d'autres outils (généralement plus méchants). On dirait que pour le reste de l'équipe, c'est de la pure magie. Ils se dirigeront vers mon bureau et demanderont une expression régulière qui me prendra littéralement dix secondes à assembler, puis seront époustouflés quand cela fonctionnera. Je ne sais pas - j'ai travaillé avec eux si longtemps, c'est tout simplement naturel à ce stade.

En l'absence de fluidité regex, vous vous retrouvez avec des combinaisons d'instructions de contrôle de flux enveloppant les instructions strstr et strpos, ce qui devient laid et difficile à exécuter dans votre tête. Je préfère de loin créer une regex élégante que trente lignes de recherche de chaînes.

Au contraire. Les gens parroient les regex sont trop souvent des mèmes maléfiques de l' OMI. Il est évident que preg_match est surutilisé php, mais il est moins évident qu'il est souvent judicieux de le faire (en PHP).

J'irais si loin et conjecturerais que c'est encore une autre microoptimisation en php land pour utiliser les fonctions de chaîne. Il y en a beaucoup et beaucoup utiles, et ils sont généralement le meilleur choix. Mais vous ne devriez pas fuir preg_matchen faveur de multiples strposet de ifchaînes. Parce qu'en pratique, il s'avère que libpcre est souvent plus rapide que PHP ne peut exécuter une boucle à la recherche d'alternatives de chaînes, par exemple

Comme un exemple récent m'a fait réaliser, tester si une chaîne est tout en minuscules:

 if ($string == strtolower($string))

Est plus lisible que:

 if (!preg_match("/[A-Z]/", $string))

Et vous supposeriez que le premier doit être plus rapide, car il est entièrement en PHP. Mais en réalité, l'expression régulière ne regarde la chaîne qu'une seule fois et peut annuler la condition annulée dès qu'elle trouve une lettre majuscule. L'approche strtolower () examine cependant la chaîne deux fois. Le premier strtolower () crée une chaîne en double en itérant sur chaque lettre, en la comparant et en la mettant en majuscule. Ensuite, l' ==itération sur l'original et la copie à nouveau, en les comparant une fois de plus.

Ce n'est donc pas un cas évident. Et pour être objectif, le premier est souvent plus rapide, car vous ne comparez normalement que des chaînes courtes. Mais il est impératif de ne pas aller aveuglément en supposant que les fonctions de chaîne PHP sont toujours recommandées par rapport aux expressions régulières.

(Je suis tenté d'ajouter une autre diatribe au sujet de la réponse amusante de @ bobince concernant les xhtml-regexes, et comment elle est récemment souvent liée de manière très inutile. Et les réponses plus objectives ci-dessous sont ignorées.)

Les expressions régulières sont très attrayantes car elles sont le meilleur outil pour analyser une langue régulière.

Ils présentent les avantages suivants:

• Ils sont concis . Il faut généralement beaucoup plus de code pour analyser un langage régulier spécifique en utilisant un algorithme spécifique que vous avez trouvé qu'avec une expression rationnelle.
• Ils sont rapides à utiliser. Il faut généralement beaucoup plus de temps pour écrire un analyseur pour une langue régulière spécifique en utilisant un algorithme spécifique que vous avez trouvé qu'avec une expression rationnelle.
• Ils sont faciles . Une fois que vous avez appris l'ensemble des caractères spéciaux et leur signification, il est facile de composer une expression rationnelle (bien qu'un peu plus difficile à lire). Les regexps sont des langues elles-mêmes - un trait utile parce que notre espèce a évolué pour être très bonne en langage.
• Ils sont rapides . Une fois compilés, ils peuvent correspondre à une longueur de chaîne Nen temps O ( N).
• Ils sont flexibles . Ils peuvent correspondre à n'importe quelle langue régulière et beaucoup de nos données sont exprimées comme une langue régulière.
• Ils sont omniprésents . La plupart des langages de programmation ont une prise en charge regexp de base - via des bibliothèques externes ou intégrés dans le langage lui-même. Il n'y a pas non plus trop de variations entre les langues d'expression régulière elles-mêmes.

Cela les rend attrayants pour les situations auxquelles ils sont adaptés, mais les gens peuvent les utiliser dans des contextes où ils ne sont pas le meilleur outil, car ils:

• Je ne comprends pas que ce à quoi ils correspondent ne peut pas être exprimé à l'aide d'une expression rationnelle (par exemple HTML).
• Sont paresseux (dans le mauvais sens) - ils connaissent un outil et reconnaissent que ce n'est pas le meilleur outil pour ce qu'ils font, mais cela fonctionnera sans problème 95% du temps et prend 95% de l'effort d'apprendre un particulier analyseur ou en écrivant un à partir de zéro.
• Ils ignorent qu'il existe de meilleurs outils.

Hmmm, je ne peux que deviner. Peut-être que certaines personnes ont expérimenté que 30 lignes de leur code ont été remplacées par une expression régulière de 20 caractères, il leur semble donc mal d'utiliser autre chose lorsque des expressions régulières peuvent être utilisées.

Cela correspond à la façon dont certaines personnes pensent. Je ne les aime pas, mais j'ai des amis qui semblent penser aux regexps. Je suppose que la partie correspondant au motif de leur cerveau est plus exposée que la logique formelle. :-)

Je pense que l'omniprésence de l'expression régulière est due à l'ubiquité des chaînes. La chaîne est la structure de données la plus simple, la première que la plupart d'entre nous apprennent. Puisque tout notre code est écrit sous forme symbolique, il est naturel pour un programmeur d'envisager de modéliser quelque chose sous forme symbolique. Mais si notre langage de programmation offre une résistance lorsque nous essayons d'étendre sa syntaxe pour nos nouvelles formes symboliques intelligentes, elles se retrouvent toutes entre guillemets. Le modèle de données relationnel dispose de SQL. Le modèle de données XML a XQuery. Mais qu'en est-il du modeste modèle de données de chaîne? Regex!

Pas plus tard qu'hier, je cherchais dans l'API un nouveau cadre Javascript brillant qui prend en charge le développement de jeux HTML5. Il dispose d'un mécanisme déclaratif pour décrire les principaux sous-systèmes dont votre jeu aurait besoin. Comment spécifie-t-on ces fonctionnalités? JSON? Notation courante des points? Un tableau? Non - une chaîne contenant une liste de noms d'entités séparés par des virgules et des espaces. Je me demande comment il analyse cette liste ...?

Parce que vous pouvez tout voir en même temps. En étant capable de voir le tout, il peut être plus facile de travailler avec, et c'est toujours agréable. C'est un peu comme la raison pour laquelle de nombreux programmeurs C ++ utilisent toujours des instructions de type printf: ce n'est pas sûr pour les types (bien que gcc puisse au moins vérifier les types sur les instructions printf), et ce n'est pas joli, mais boy est-il compact et utilisable.

Si c'est une expression assez simple, alors ils SONT souvent la meilleure façon de faire les choses - leur forme compacte et leurs nombreuses capacités les rendent parfaits pour certaines tâches. Le problème survient lorsque vous rendez la regex si compliquée que vous ne pouvez plus la lire, ou lorsque vous utilisez une regex complexe pour faire quelque chose qui pourrait être fait plus rapidement via de simples opérations de chaîne.

Regex, comme tout autre outil puissant, doit être utilisé avec modération appropriée - ni trop, ni trop peu. Et à moins que les performances ne soient un gros problème, une seule expression régulière peut parfois être plus rapide à écrire et plus facile à déboguer qu'une série d'opérations de chaîne.

Hmm, les réponses actuelles sont trop centrées sur les aspects techniques et les avantages / inconvénients de lisibilité (ce qui est un point important). Alors permettez-moi d'essayer de le déplacer un peu plus sur l'environnement / la communauté PHP:

• PHP est la petite- soeur de Perls . Et les expressions régulières font partie intégrante de Perl (ils ont inventé ce genre de choses, n'est-ce pas?). C'est donc une des raisons pour lesquelles les regexps sont omniprésentes en PHP.
• Le cas d'utilisation de PHP n'est pas fortuit contrairement au cas d'utilisation des expressions régulières. PHP est structurellement utilisé pour coller ensemble des pages HTML. Et les regexps fonctionnent sur du texte. (ce que WReach a dit)
• Micro optimisation . Comme mentionné précédemment: les gens utilisent fréquemment des expressions régulières et / ou des fonctions de chaîne PHP après la vitesse perçue. Un problème central dans les cercles PHP, non spécifique aux regexps.
• Les expressions régulières sont construites en . En Python, en Java, en C #, en Ruby? il y a de la disponibilité, mais un élément dissuasif de devoir charger un module supplémentaire. Et voyez comment en PHP ou Javascript où c'est une fonctionnalité de base, le modèle d'utilisation diffère. Une autre exposition: CSS où il est de plus en plus utilisé.
• Le manuel PHP est en faute. C'est souvent le cas. Les expressions régulières sont facilement détectables, et j'ai reporté ce fait amusant parce que c'est ennuyeux dans son évidence: tous les maudits tutoriels et livres d'introduction PHP enseignent toujours les expressions régulières, mais échouent à éduquer sur les cas d'utilisation.
• L' API de chaîne en PHP a été conçu par les mêmes personnes qui vous ont amené les guillemets magiques et l'espace de noms \ séparateur. C'est englobant, meilleur que Java, mais pas glamour dans son intégralité. En particulier, si les chaînes peuvent doubler en tant qu'objets (voir Python), les fonctions de chaîne peuvent dépasser les regexps.

Mais c'est juste comme notes secondaires. Je crois que c'est de toute façon principalement des raisons de perception et techniques qui conduisent à une surutilisation et / ou à une élimination des expressions régulières en général. Pourtant, PHP et sa base d'utilisateurs ont quelques propriétés qui le composent, et pourquoi nous voyons plus de questions sur SO à ce sujet [citation nécessaire!] Et ils sont "morbidement attractifs" là-bas.

J'aime les expressions régulières en général, je les trouve plus faciles à lire / à comprendre que les 20 lignes de code avec lesquelles je devrais les remplacer. Les expressions régulières courtes sont rapidement lues et comprises et elles sont relativement faciles à maintenir (si l'expression change, vous n'avez qu'une seule ligne à changer par rapport à la recherche à travers les 20 lignes de code pour effectuer le changement). Il y a des moments où ils sont mal utilisés, mais il en est de même de bien d'autres choses.

La raison pour laquelle vous voyez probablement autant d'abus est parce que vous parcourez la section PHP de StackOverFlow car je suis sûr que vous savez qu'il y a beaucoup de programmeurs PHP immatures umm là-bas.

Pourquoi les expressions régulières sont-elles si morbides?

Ils ne sont pas. Ils sont vraiment laids comme l'enfer. Et incompréhensible. C'est une abomination qui devrait être tuée dès que possible.

Maintenant, cela étant dit, je reviens au débogage d'une petite application Perl. Je ne peux pas m'en empêcher; malheureusement, ils sont parfois le meilleur outil pour le travail.

L'homme est une créature utilisatrice d'outils, et les expressions régulières sont des outils puissants. Une belle métaphore pour les expressions régulières est une trancheuse à viande d'une charcuterie. Si vous voulez des tranches de dinde, du corned-beef, etc., comme du papier, c'est juste la chose. Cependant, vous avez besoin de mains qualifiées pour l'utiliser, car vous pouvez vous couper très mal avec lui et vous ne sentirez rien avant de voir le sang. Ce que je veux dire par là, c'est que le gros problème avec les expressions régulières est de les retirer légèrement signifie que vous faites correspondre quelque chose que vous ne devriez pas, ou vice versa, et vous ne le découvrez pas jusqu'à ce que cela cause un problème plus loin dans le processus.

Les expressions régulières sont très attrayantes car elles détiennent du pouvoir. Vous pouvez faire un travail très compliqué en très peu de caractères.

Le problème est que la construction d'expression régulière standard est pas Turing-complet qui signifie qu'il ya des programmes que vous ne pouvez pas mettre en œuvre avec une expression régulière, et les gens ne SAIS que quand ils sont attirés par la puissance apparente des expressions régulières.

C'est - je suppose - la raison de la citation jwz de "maintenant ils ont deux problèmes".

Je suppose que les expressions régulières de Perl sont complètes de Turing, mais apparemment, cela n'a pas encore été prouvé ou réfuté de manière décisive.

Parce que c'est un moyen efficace de programmer une machine à états finis, qui est un outil puissant lorsqu'il s'applique. C'est fondamentalement son propre langage pour programmer les FSM, ce qui est utile si vous connaissez la langue, ennuyeux si vous ne le savez pas.

Dans mon expérience, les regex sont comme un art ancien, quelque chose d'obscur, certains les ressentent parce qu'ils ne peuvent pas comprendre la sorcellerie impliquée et peut-être parce que personne ne vous les expliquera. Je n'ai pas entendu parler d'universités qui leur enseignent quelque chose de moins trivial que de faire correspondre un e-mail. Ensuite, il y a le fonctionnement interne mystique de cela, puisque la plupart des gens ne les comprennent pas, ils doivent être lents . Et les faire fonctionner correctement du premier coup est toujours un défi pour les nouveaux arrivants.

La même chose peut être dite à propos de Perl, awk, Linux et tout ce qui n'a pas de boutons brillants ou une belle syntaxe colorée. Donc, c'est comme une complexité supplémentaire pour les "tâches triviales", il suffit de lancer des boucles, des divisions, un interrupteur, de la magie et c'est tout, quelque chose qui pourrait fonctionner. Mais bon, si vous êtes de l'autre côté de la route, les regex sont de magnifiques emporte-pièces qui ressemblent à du bruit de signal sans boucles désagréables ou plus de choses à déboguer. Je les aime aussi pour la flexibilité qu'ils offrent. Lorsque le modèle pour correspondre change, vous changez simplement l'expression régulière, pas l'algorithme, ou l'outil / quoi que ce soit, et c'est agréable et fonctionne à nouveau. Et comme il s'agit d'une chaîne magique, vous pouvez la mettre en dehors du code source si vous le souhaitez. Et une autre chose qui me fait penser à Perl, si vous écrivez un regex de plus de 20 caractères, il vous semble que vous avez accompli beaucoup, au moins pour moi, c'est tellement soigné et compact. Je suis aussi un programmeur paresseux, je n'aime pas écrire beaucoup de code avec une belle identification et des commentaires et ajouter quelques bugs au mix.