Qu'entend-on par «maintenant vous avez deux problèmes»?


200

Il y a une citation populaire de Jamie Zawinski :

Certaines personnes, confrontées à un problème, pensent "Je sais, je vais utiliser des expressions régulières." Maintenant, ils ont deux problèmes.

Comment cette citation est-elle censée être comprise?


46
Le 2ème problème est qu'ils utilisent regex et n'ont toujours pas résolu le premier problème, d'où 2 problèmes.
Ampt

24
@Euphoric - en fait, un bon code est court - mais sans être concis de manière cryptique.
Steve314

24
@IQAndreas: Je pense que ça se veut semi-humoristique. Le commentaire qui est fait est que si vous ne faites pas attention, l'utilisation d'expressions régulières peut aggraver la situation au lieu de l'améliorer.
FrustratedWithFormsDesigner

145
Certaines personnes, en essayant d'expliquer quelque chose, pensent: "Je sais, je vais utiliser une citation de Jamie Zawinski." Maintenant, ils ont deux choses à expliquer.
Détly

Réponses:


220

Certaines technologies de programmation ne sont généralement pas bien comprises par les programmeurs ( expressions régulières , virgule flottante , Perl , AWK , IoC ... et autres ).

Celles-ci peuvent être des outils incroyablement puissants pour résoudre le bon ensemble de problèmes. Les expressions régulières en particulier sont très utiles pour faire correspondre les langues ordinaires. Et il y a le nœud du problème: peu de gens savent comment décrire un langage courant (cela fait partie de la théorie informatique / linguistique qui utilise des symboles amusants - vous pouvez en lire plus à la hiérarchie de Chomsky ).

Lorsque vous traitez avec ces choses, si vous les utilisez mal, il est peu probable que vous ayez réellement résolu votre problème initial. En utilisant une expression régulière pour correspondre HTML (une occurrence beaucoup trop commune) signifie que vous allez manquer cas de pointe. Et maintenant, vous avez toujours le problème original que vous n'avez pas résolu, et un autre bogue subtil qui a été introduit en utilisant la mauvaise solution.

Cela ne veut pas dire que les expressions régulières ne devraient pas être utilisées, mais plutôt que l'on devrait travailler pour comprendre ce que l'ensemble des problèmes peuvent être résolus et ne peuvent pas être résolus et utilisé judicieusement.

La clé de la maintenance du logiciel est l'écriture de code maintenable. L'utilisation d'expressions régulières peut aller à l'encontre de cet objectif. Lorsque vous travaillez avec des expressions régulières, vous avez écrit un mini-ordinateur (en particulier un automate à états finis non déterministe ) dans un langage spécifique à un domaine. Il est facile d’écrire l’équivalent de «Hello world» dans ce langage et d’y gagner une confiance rudimentaire, mais il faut aller plus loin avec la compréhension du langage courant pour éviter d’écrire des bogues supplémentaires qui peuvent être très difficiles à identifier et à corriger (car ils ne font pas partie du programme dans lequel l'expression régulière est).

Alors maintenant, vous avez un nouveau problème; vous avez choisi l'outil de l'expression régulière pour le résoudre (lorsqu'il est inapproprié), et vous avez maintenant deux bogues, qui sont tous deux plus difficiles à trouver, car ils sont cachés dans une autre couche d'abstraction.


8
Je ne suis pas sûr que Perl lui-même fasse partie d'une liste de technologies mal comprises par les programmeurs;)
crad de

21
@crad, c’est plus qu’on l’a déjà dit à propos de perl ... Beaucoup de gens l’ont entendu popularisé. J'aime toujours la virgule flottante dans la conversation: "Maintenant, vous avez des problèmes 2.00000152"

56
@crad Certaines personnes, confrontées à un problème, pensent "Je sais, je vais utiliser perl." Maintenant, ils ont des problèmes $ (^ @ #% () ^%) (#).
Michael Hampton

4
@Jens en fait, la puissance supplémentaire de PCRE par rapport aux expressions rationnelles traditionnelles en fait une solution plus séduisante et plus difficile à maintenir. Les automates finis auxquels le PCRE correspond sont explorés dans Extension des automates finis pour correspondre efficacement aux expressions régulières compatibles Perl ... et ce n'est pas une mince affaire. Au moins , avec l'expression rationnelle traditionnelle, on peut obtenir leur tête autour de lui sans trop de mal une fois que les concepts nécessaires sont compris.

6
Vous faites un bon point. les expressions régulières sont en réalité une seconde langue non triviale. Même si le programmeur d'origine est compétent dans la langue principale et que le style de regex est utilisé, ajouter une "deuxième langue" signifie que les mainteneurs connaîtront moins les probabilités. Sans oublier que la lisibilité des expressions rationnelles est souvent inférieure à celle du langage "hôte".
JS.

95

Les expressions régulières - en particulier celles qui ne sont pas triviales - sont potentiellement difficiles à coder, à comprendre et à maintenir. Il suffit de regarder le nombre de questions sur Stack Overflow marquées [regex]où le questionneur a supposé que la réponse à son problème était une regex et se sont ensuite bloquées. Dans de nombreux cas, le problème peut (et devrait peut-être) être résolu différemment.

Cela signifie que si vous décidez d'utiliser une expression régulière, vous avez maintenant deux problèmes:

  1. Le problème initial que vous vouliez résoudre.
  2. Le support d'une regex.

En gros, je pense qu’il signifie que vous ne devriez utiliser une regex que s’il n’ya pas d’autre moyen de résoudre votre problème. Une autre solution sera probablement plus facile à coder, à maintenir et à supporter. Cela peut être plus lent ou moins efficace, mais si ce n’est pas essentiel, la facilité de maintenance et d’assistance devrait être la principale préoccupation.


27
Et pire: ils sont juste assez puissants pour amener les gens à essayer de les utiliser pour analyser des choses qu’ils ne peuvent pas, comme le HTML. Voir les nombreuses questions sur SO sur "comment analyser le HTML?"
Frank Shearar

6
Pour certaines situations, regex est génial. Dans beaucoup d'autres cas, pas tellement. À l’autre bout, c’est un terrible gouffre de désespoir. Le problème se pose souvent lorsque quelqu'un découvre ces informations pour la première fois et commence à voir des applications partout. Un autre dicton célèbre: "Lorsque vous ne disposez que d'un marteau, tout ressemble à un clou".
Todd Williamson

3
Cela signifie-t-il que par le nombre de questions de la balise SO [c #], il s’agit du langage de programmation le plus difficile à comprendre?

2
Je préférerais de loin voir une expression régulière complexe plutôt qu'une longue série d'appels à des méthodes de chaîne. OTOH, je déteste vraiment voir des expressions régulières mal utilisées pour analyser des langages complexes.
Kevin Cline

5
"En gros, je pense qu'il signifie que vous ne devriez utiliser une expression régulière que s'il n'y a pas d'autre moyen de résoudre votre problème. Toute autre solution sera plus facile à coder, à maintenir et à supporter." - sérieusement en désaccord .. Les regex sont d'excellents outils, il suffit de connaître leurs limites. De nombreuses tâches peuvent être codées de manière plus élégante avec des regex. (mais, juste pour faire un exemple, vous ne devriez pas les utiliser pour analyser HTML)
Karoly Horvath

69

C'est surtout une blague ironique, mais avec un grain de vérité.

Il existe certaines tâches pour lesquelles les expressions régulières conviennent parfaitement. Une fois, j’ai remplacé 500 lignes de code d’analyseur de descente récursif écrit manuellement par une expression régulière dont le débogage complet a pris environ 10 minutes. Les gens disent que les expressions rationnelles sont difficiles à comprendre et à déboguer, mais que celles appliquées correctement ne sont pas aussi difficiles à déboguer qu'un énorme analyseur conçu à la main. Dans mon exemple, il a fallu deux semaines pour déboguer tous les cas extrêmes de la solution sans regex.

Cependant, pour paraphraser Oncle Ben:

Avec une grande expressivité vient une grande responsabilité.

En d’autres termes, les expressions rationnelles ajoutent de l’expressivité à votre langue, mais cela incombe davantage au programmeur de choisir le mode d’expression le plus lisible pour une tâche donnée.

Certaines choses semblent initialement une bonne tâche pour les expressions régulières, mais ne le sont pas. Par exemple, tout élément comportant des jetons imbriqués, tel que HTML. Parfois, les gens utilisent une expression régulière lorsqu'une méthode plus simple est plus claire. Par exemple, string.endsWith("ing")est plus facile à comprendre que l'expression régulière équivalente. Parfois, les gens essaient de mettre un gros problème dans un regex simple, où le décomposer en morceaux est plus approprié. Parfois, les gens ne parviennent pas à créer les abstractions appropriées, répétant une expression régulière plusieurs fois au lieu de créer une fonction bien nommée pour effectuer le même travail (peut-être implémentée en interne avec une expression régulière).

Pour une raison quelconque, les expressions rationnelles ont une tendance étrange à créer un angle mort par rapport aux principes d'ingénierie logicielle habituels, tels que la responsabilité unique et DRY. C'est pourquoi même les personnes qui les aiment les trouvent parfois problématiques.


10
Oncle Ben n'a-t-il pas dit non plus "Des résultats parfaits, à chaque fois"? C’est peut-être pour cette raison que les gens se sentent si heureux avec les regex ...
Andrzej Doyle

4
Le problème avec regex concernant HTML qui surprend des développeurs inexpérimentés est que HTML a une grammaire sans contexte, non régulière: regex peut être utilisé pour une simple analyse HTML (ou XML) (par exemple, en récupérant une URL à partir d'une balise d'ancrage nommée), mais n'est pas bien adapté à quelque chose de complexe. Pour cela, l'analyse DOM est plus appropriée. Lecture connexe: Hiérarchie de Chomsky .

53

Jeff Atwood fait ressortir une interprétation différente dans un article de blog traitant de cette citation: Expressions régulières: vous avez maintenant deux problèmes (merci à Euphoric pour le lien)

En analysant le texte intégral des publications de Jamie dans le fil de discussion original de 1997, on constate ce qui suit:

La nature de Perl encourage l'utilisation d'expressions régulières presque à l'exclusion de toutes les autres techniques. ils sont de loin le moyen le plus "évident" (du moins pour ceux qui ne connaissent pas mieux) de se rendre du point A au point B.

La première citation est trop simple pour être prise au sérieux. Mais cela, je suis complètement d'accord avec. Voici ce que Jamie essayait de dire: ce n'est pas que les expressions régulières soient pervers en soi, mais le fait de les utiliser à l'excès est mauvais.

Même si vous ne comprenez des expressions régulières, vous courez dans le marteau d' or problème, en essayant de résoudre un problème avec des expressions régulières, quand il aurait été plus facile et plus clair pour faire la même chose avec le code régulier (voir aussi CodingHorror: utilisation Regex Abus de regex ).

Il existe un autre article de blog qui examine le contexte de la citation et entre plus de détails qu'Atwood: Blog de Jeffrey Friedl: Source de la célèbre citation «Maintenant, vous avez deux problèmes»


3
C'est, à mon sens, la meilleure réponse car cela ajoute du contexte. Les critiques de jwz sur les regexes concernaient autant Perl que tout autre chose.
Evicatos

3
@Evicatos Il y avait encore plus de recherches effectuées sur le même fil de 1997 dans un autre article de blog: regex.info/blog/2006-09-15/247
IQAndreas

30

Il y a quelques choses qui se passent avec cette citation.

  1. La citation est une reformulation d'une blague antérieure:

    Chaque fois que nous sommes confrontés à un problème, certaines personnes disent "Utilisons AWK". Maintenant, ils ont deux problèmes. - D. Tilbrook

    C'est une blague et une vraie fouille, mais c'est aussi une façon de mettre en évidence regex comme une mauvaise solution en la reliant à d'autres mauvaises solutions. C'est un grand moment ha ha ha seul .

  2. Pour moi - remarquez, cette citation est volontairement ouverte à interprétation - le sens est simple. Le simple fait d’annoncer l’idée d’utiliser une expression régulière n’a pas résolu le problème. En outre, vous avez augmenté la complexité cognitive du code en ajoutant un langage supplémentaire avec des règles distinctes de la langue que vous utilisez.

  3. Bien que drôle comme une blague, vous devez comparer la complexité d'une solution non regex avec la complexité de la solution regex + la complexité supplémentaire d'inclure des regex. Il peut être intéressant de résoudre un problème avec une expression rationnelle, malgré le coût supplémentaire lié à l’ajout de expressions rationnelles.


21

Des expressions régulières sont maintenant présentes ou plus que tout autre contenu non formaté; en fait, il est vraisemblable que nous avons probablement dépassé le nombre de morceaux, mais malheureusement, leur comportement a donné lieu à des mises en œuvre qui ne laissaient pas beaucoup de place à des hommes et des personnes.

(Les expressions régulières ne sont pas pires à lire ou à maintenir que tout autre contenu non formaté; en effet, une expression rationnelle est probablement plus facile à lire que ce texte ici - mais malheureusement, ils ont une mauvaise réputation car certaines implémentations n'autorisent pas la mise en forme et les gens en général ne sais pas que tu peux le faire.)


Voici un exemple trivial:

^(?:[^,]*+,){21}[^,]*+$


Ce qui n’est pas vraiment difficile à lire ou à maintenir de toute façon, mais est encore plus facile quand il ressemble à ceci:

(?x)    # enables comments, so this whole block can be used in a regex.
^       # start of string

(?:     # start non-capturing group
  [^,]*+  # as many non-commas as possible, but none required
  ,       # a comma
)       # end non-capturing group
{21}    # 21 of previous entity (i.e. the group)

[^,]*+  # as many non-commas as possible, but none required

$       # end of string

C'est un exemple un peu excessif (commenter $s'apparente à commenter i++), mais il est clair qu'il ne devrait y avoir aucun problème à lire, comprendre et maintenir cela.


Tant que vous savez clairement quand les expressions régulières conviennent et lorsqu'elles sont une mauvaise idée, elles ne présentent aucun inconvénient et la plupart du temps, la citation JWZ ne s'applique pas vraiment.


1
Bien sûr, mais je ne cherche pas à discuter des mérites des regex, et je n’aimerais pas voir cette discussion se dérouler ainsi. J'essaie juste de comprendre où il voulait en venir.
Paul Biggar

1
Ensuite, le lien dans le commentaire de livibetter vous indique ce que vous devez savoir. Cette réponse indique simplement qu'il n'est pas nécessaire que les expressions rationnelles soient obscures et que la citation est donc absurde.
Peter Boughton

8
Quel est le point d'utilisation *+? En quoi est-ce différent (fonctionnellement) de juste *?
Timwi

1
Bien que ce que vous dites puisse être vrai, cela ne répond pas à cette question précise. Votre réponse se résume à "à mon avis, cette citation n’est généralement pas vraie". La question n'est pas de savoir si c'est vrai ou pas, mais ce que signifie la citation.
Bryan Oakley

2
Il n'y a littéralement aucun intérêt à le faire *+dans ce cas; tout est ancré et peut être associé en un seul passage par un automate pouvant compter jusqu'à 22. Le modificateur correct sur ces ensembles sans virgule est tout simplement ancien *. (De plus, il ne devrait y avoir aucune différence entre les algorithmes d'appariement glouton et non glouton. C'est un cas extrêmement simple.)
Donal Fellows

14

En plus de la réponse de ChrisF, à savoir que les expressions rationnelles "sont difficiles à coder, à comprendre et à maintenir", il y a pire: elles sont juste assez puissantes pour inciter les gens à essayer de les utiliser pour analyser des éléments qu'ils ne peuvent pas, tels que HTML. Voir les nombreuses questions sur SO sur "comment analyser le HTML?" Par exemple, la réponse la plus épique de tous!


14

Les expressions régulières sont très puissantes, mais elles ont un petit et un gros problème; ils sont difficiles à écrire et presque impossibles à lire.

Dans le meilleur des cas, l'utilisation de l'expression régulière résout le problème. Vous n'avez donc que le problème de maintenance du code compliqué. Si vous ne comprenez pas correctement l'expression régulière, vous rencontrez à la fois le problème initial et le problème du code illisible qui ne fonctionne pas.

Parfois, les expressions régulières sont appelées code en écriture seule. Face à une expression régulière à corriger, il est souvent plus rapide de recommencer à zéro que d'essayer de comprendre l'expression.


1
Le vrai problème est que les expressions rationnelles ne peuvent pas implémenter, par exemple, un analyseur syntaxique, car elles ne peuvent pas comptabiliser leur profondeur imbriquée.

4
@ Thorbjørn Ravn Andersen: C'est plus une limitation qu'un problème. Ce n'est un problème que si vous essayez d'utiliser des expressions régulières pour cela, et ce n'est pas un problème avec les expressions régulières, c'est un problème avec votre choix de méthode.
Guffa

1
Vous pouvez utiliser les RE parfaitement pour le lexer (enfin, pour la plupart des langues), mais l'assemblage du flux de jetons dans un arbre d'analyse (c'est-à-dire, l' analyse ) les dépasse formellement.
Donal Fellows

10

Le problème est que regex est une bête compliquée, et vous ne résolvez votre problème que si vous utilisez parfaitement regex. Si vous ne le faites pas, vous vous retrouvez avec 2 problèmes: votre problème initial et regex.

Vous prétendez que cela peut faire le travail de cent lignes de code, mais vous pouvez également argumenter que 100 lignes de code clair et concis sont préférables à une ligne de regex.

Si vous avez besoin de preuves: vous pouvez consulter ce SO Classic ou tout simplement passer au peigne le tag SO Regex


8
Aucune des affirmations de votre première phrase n'est vraie. Regex n'est pas particulièrement compliqué et, comme aucun autre outil, vous devez le connaître parfaitement pour résoudre les problèmes qui y sont associés. C'est juste FUD. Votre deuxième paragraphe est tout à fait ridicule: vous pouvez bien sûr argumenter. Mais ce n'est pas un bon.
Konrad Rudolph

1
@ KonradRudolph Je pense que le fait qu'il existe de nombreux outils de génération et de validation de regex montre que cette dernière est un mécanisme compliqué. Il est illisible (de par sa conception) et peut entraîner un changement complet de flux pour quelqu'un qui modifie ou écrit un morceau de code qui utilise regex. Quant à la deuxième partie, je pense que cela ressort clairement du vaste regroupement de connaissances sur P.SE et du dicton "Le code de débogage est deux fois plus difficile que de l’écrire, donc si vous écrivez le code le plus intelligent possible, vous sont, par définition, pas assez intelligents pour le déboguer "
Ampt

2
Ce n'est pas un argument approprié. Oui, bien sûr, les regex sont complexes. Mais les autres langages de programmation le sont aussi. Regex est considérablement moins complexe que la plupart des autres langages, et les outils existants pour regex sont dépassés par des outils de développement pour d'autres langages (FWIW, je travaille beaucoup avec regex et je n'ai jamais utilisé de tels outils…). C'est une vérité simple: même les expressions rationnelles complexes sont plus simples qu'un code d'analyse équivalent non-regex.
Konrad Rudolph

@ KonradRudolph Je pense que nous avons un désaccord fondamental sur la définition du mot simple alors. Je vais vous dire que la regex peut être plus efficace ou même plus puissante, mais je ne pense pas que ce soit un mot aussi simple que celui qui vient à l'esprit de quiconque pense à la regex.
Ampt

Peut-être que nous le faisons, mais ma définition est applicable: je veux dire simple, facile à comprendre, facile à maintenir, peu d'insectes cachés, etc. Bien sûr, une expression rationnelle complexe ne semblera pas très compréhensible à première vue . Mais il en va de même pour un morceau de code équivalent non regex. Je n'ai jamais dit que les regex sont simples. Je dis qu'ils sont plus simples - je compare. C'est important.
Konrad Rudolph

7

La signification a deux parties:

  • Tout d'abord, vous n'avez pas résolu le problème initial.
    Cela renvoie probablement au fait que les expressions régulières offrent souvent des solutions incomplètes aux problèmes courants.
  • Deuxièmement, vous avez maintenant ajouté une difficulté supplémentaire liée à la solution que vous avez choisie.
    Dans le cas d'expressions régulières, la difficulté supplémentaire fait probablement référence à la complexité, à la facilité de maintenance ou à la difficulté supplémentaire liée à l'adaptation d'expressions régulières à un problème qu'elle n'était pas censée résoudre.

7

Comme vous le demandez en 2014, il serait intéressant de se concentrer sur les idéologies des langages de programmation du contexte de 1997 par rapport au contexte actuel. Je ne vais pas entrer dans ce débat ici, mais les opinions sur Perl et sur Perl lui-même ont beaucoup changé.

Cependant, pour rester dans un contexte 2013 ( de l'eau un sous les ponts coulé DEPUIS), je suggère de mettre l' accent sur la reconstitution de citations en utilisant une célèbre bande dessinée XKCD qui est une citation directe de Jamie Zawinski One :

Une bande dessinée de XKCD sur les regex, Perl et les problèmes

Tout d' abord , j'ai eu des problèmes à comprendre cette bande dessinée parce qu'il était une référence à la Zawinski citation, et une citation d'un paroles de chansons de Jay-z, et une référence de GNU program --help -zdrapeau 2 , donc, il était trop culture pour moi de le comprendre.

Je savais que c'était amusant, je le ressentais, mais je ne savais pas vraiment pourquoi. Les gens font souvent des blagues sur Perl et les regex, d'autant plus que ce n'est pas le langage de programmation le plus branché, vous ne savez pas vraiment pourquoi c'est supposé être amusant ... Peut-être parce que les meneurs de Perl font des bêtises .

Donc, la citation initiale semble être une blague sarcastique basée sur des problèmes réels (douleur?) Causés par la programmation avec des outils qui font mal. Tout comme un marteau peut faire mal à un maçon, programmer avec des outils qui ne sont pas ceux qu'un développeur choisirait s’il pouvait peut faire mal (le cerveau, les émotions). Parfois, de grands débats sur l'outil est le meilleur produit, mais il est presque sans valeur parce que c'est un problème de votre goût ou votre goût de l' équipe de programmation , culturelles ou économiques raisons. Une autre excellente bande dessinée XKCD à ce sujet:

Une BD de XKCD sur les débats sur les outils de programmation

Je peux comprendre les personnes qui ressentent de la douleur à propos des regex, et ils croient qu'un autre outil est mieux adapté à l'usage pour lequel les regex sont conçus. Comme @ karl-bielefeldt répond à votre question avec une grande expressivité, il y a une grande responsabilité , et les expressions rationnelles sont particulièrement concernées par cela. Si un développeur ne s'inquiète pas de la façon dont il gère les expressions rationnelles, cela finira par être pénible pour les personnes qui conserveront le code ultérieurement.

Je terminerai avec cette réponse à propos de la reconstitution de citations par une citation montrant un exemple typique tiré des meilleures pratiques Perl de Damian Conw (un livre de 2005).

Il explique qu'écrire un motif comme celui-ci:

m{'[^\\']*(?:\\.[^\\']*)*'}

... n'est pas plus acceptable que d'écrire un programme comme celui-ci :

sub'x{local$_=pop;sub'_{$_>=$_[0
]?$_[1]:$"}_(1,'*')._(5,'-')._(4
,'*').$/._(6,'|').($_>9?'X':$_>8
?'/':$")._(8,'|').$/._(2,'*')._(
7,'-')._(3,'*').$/}print$/x($=).
x(10)x(++$x/10).x($x%10)while<>;

Mais cela peut être réécrit , ce n’est toujours pas joli, mais au moins il est maintenant possible de survivre.

# Match a single-quoted string efficiently...
m{ '            # an opening single quote
    [^\\']*     # any non-special chars (i.e., not backslash or single quote)
    (?:         # then all of...`
    \\ .        # any explicitly backslashed char
    [^\\']*     #    followed by any non-special chars
    )*          # ...repeated zero or more times
    '           # a closing single quote
}x

Ce type de code de forme rectangulaire est le deuxième problème, pas les expressions rationnelles pouvant être formatées de manière claire, facile à gérer et lisible.


2
/* Multiply the first 10 values in an array by 2. */ for (int i = 0 /* the loop counter */; i < 10 /* continue while it is less than 10 */; ++i /* and increment it by 1 in each iteration */) { array[i] *= 2; /* double the i-th element in the array */ }
5gon12eder

6

S'il y a une chose que vous devriez apprendre de l'informatique, c'est la hiérarchie de Chomsky . Je dirais que tous les problèmes avec les expressions régulières proviennent de tentatives d’analyse de la grammaire sans contexte. Lorsque vous pouvez imposer une limite (ou pensez pouvoir imposer une limite) aux niveaux d'imbrication dans CFG, vous obtenez ces expressions régulières longues et complexes.


1
Oui! Les personnes qui étudient des expressions régulières sans cette origine CS ne comprennent pas toujours qu’il existe certaines choses qu’une expression rationnelle ne peut mathématiquement pas faire.
benzado

5

Les expressions régulières conviennent mieux à la génération de jetons qu'à l'analyse complète.

Cependant, un ensemble étonnamment important d'éléments que les programmeurs doivent analyser sont analysables par un langage standard (ou, pire, presque par un langage standard et si vous écrivez un peu plus de code ...).

Donc, si on est habitué à "aha, je dois séparer le texte, je vais utiliser une expression régulière", il est facile de suivre cette voie, quand vous avez besoin de quelque chose qui ressemble plus à un automate à pile, un analyseur CFG ou grammaires encore plus puissantes. Cela se termine généralement en larmes.

Donc, je pense que la citation n'est pas tellement une expression rationnelle qui claque, elle a son utilisation (et est bien utilisée, elle est vraiment très utile), mais une confiance excessive dans l'utilisation d'une expression rationnelle (ou, en particulier, son choix non critique) .


3

Jwz est simplement hors de son rocker avec cette citation. les expressions régulières ne sont pas différentes des fonctionnalités linguistiques: faciles à bousiller, difficiles à utiliser avec élégance, parfois puissantes, parfois inappropriées, souvent bien documentées, souvent utiles.

il en va de même pour l'arithmétique en virgule flottante, les fermetures, l'orientation des objets, les E / S asynchrones ou toute autre chose que vous pouvez nommer. si vous ne savez pas ce que vous faites, les langages de programmation peuvent vous rendre triste.

si vous pensez que les expressions rationnelles sont difficiles à lire, essayez de lire l'implémentation de l'analyseur équivalent pour utiliser le modèle en question. les expressions rationnelles gagnent souvent parce qu'elles sont plus compactes que les analyseurs syntaxiques complets ... et dans la plupart des langues, elles sont également plus rapides.

Ne vous découragez pas d'utiliser des expressions régulières (ou toute autre fonctionnalité linguistique), car un blogueur qui s'auto-promeut fait des déclarations non qualifiées. essayez par vous-même et voyez ce qui fonctionne pour vous.


1
FWIW, l’arithmétique en virgule flottante est plus compliquée que les RE, mais semble plus simple. Il faut se méfier! (Au moins les RE délicates ont tendance à avoir l'air dangereux.)
Donal Fellows

3

Ma réponse préférée et détaillée à cette question est donnée par le célèbre Rob Pike dans un billet de blog reproduit à partir d'un commentaire de code interne de Google: http://commandcenter.blogspot.ch/2011/08/expressions-in-lexing- et.html

En résumé, ce n’est pas qu’ils sont mauvais , mais ils sont fréquemment utilisés pour des tâches pour lesquelles ils ne sont pas forcément adaptés, en particulier s’il s’agit de lexer et d’analyser certaines entrées.

Les expressions régulières sont difficiles à écrire, bien à écrire et peuvent coûter cher par rapport à d’autres technologies ... Par contre, les Lexers sont assez faciles à écrire correctement (si ce n’est pas aussi compact) et très faciles à tester. Envisagez de trouver des identificateurs alphanumériques. Ce n'est pas trop difficile d'écrire l'expression rationnelle (quelque chose comme "[a-ZA-Z _] [a-ZA-Z_0-9] *"), mais ce n'est pas beaucoup plus difficile d'écrire comme une simple boucle. Les performances de la boucle seront cependant beaucoup plus élevées et impliqueront beaucoup moins de code sous les couvertures. Une bibliothèque d'expressions régulières est une grande chose. Utiliser un pour analyser les identifiants revient à utiliser une Ferrari pour aller au magasin chercher du lait.

Il en dit plus que cela, arguant que les expressions rationnelles sont utiles, par exemple, la correspondance jetable de modèles dans des éditeurs de texte, mais devraient rarement être utilisées dans du code compilé, etc. Cela vaut la peine d'être lu.


0

Ceci est lié à l'épigramme # 34 d'Alan Perlis:

La chaîne est une structure de données rigide et partout où elle est passée, le processus fait double emploi. C'est un véhicule idéal pour cacher des informations.

Donc, si vous choisissez la chaîne de caractères comme structure de données (et, naturellement, un code basé sur regex comme algorithme pour le manipuler), vous rencontrez un problème, même si cela fonctionne: une mauvaise conception autour d'une représentation inappropriée de données difficile à étendre et inefficace.

Cependant, souvent, cela ne fonctionne pas: le problème initial n'est pas résolu, vous avez donc deux problèmes.


0

Les expressions rationnelles sont largement utilisées pour l'analyse de texte rapide et sale. C'est un excellent outil pour exprimer des motifs un peu plus complexes qu'une simple correspondance de chaîne.

Cependant, au fur et à mesure que les expressions rationnelles se font plus complexes, des problèmes serveuraux se posent.

  1. La syntaxe des expressions rationnelles est optimisée pour une correspondance simple, la plupart des caractères correspondent eux-mêmes. C'est parfait pour les modèles simples, mais une fois que vous vous retrouvez avec plus de deux niveaux d'imbrication, vous obtenez quelque chose qui ressemble davantage à du bruit de ligne qu'à un code bien structuré. J'imagine que vous pourriez écrire une expression rationnelle sous la forme d'une série de chaînes concaténées avec indentation et commentaires entre-deux pour montrer la structure du code, mais il semble rare que cela se produise.
  2. Seuls certains types de correspondance de texte conviennent bien aux regex. Vous vous retrouvez souvent avec un analyseur syntaxique rapide et sale basé sur un langage de balisage, mais vous essayez ensuite de couvrir davantage de cas et vous trouvez que les regexes deviennent de plus en plus complexes et de moins en moins lisibles.
  3. La complexité temporelle d'une expression régulière peut être non obvoius. Il n’est pas difficile de se retrouver avec un modèle qui fonctionne très bien quand il correspond mais qui présente une complexité de O (2 ^ n) dans certains cas de non-correspondance .

Ainsi, il est trop facile de commencer par un problème de traitement de texte, d'appliquer des expressions régulières et d'obtenir deux problèmes, le problème d'origine que vous tentiez de résoudre et le traitement des expressions régulières qui tentent de résoudre (mais ne résolvent pas correctement). le problème d'origine.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.