Pourquoi les expressions régulières sont-elles si controversées? [fermé]

Lors de l'exploration des expressions régulières (autrement connues sous le nom de RegEx-es), de nombreuses personnes semblent considérer les expressions régulières comme le Saint Graal. Quelque chose qui semble si compliqué - doit juste être la réponse à toute question. Ils ont tendance à penser que chaque problème peut être résolu à l'aide d'expressions régulières.

D'un autre côté, il y a aussi beaucoup de gens qui essaient à tout prix d'éviter les expressions régulières. Ils essaient de trouver un moyen de contourner les expressions régulières et acceptent un codage supplémentaire juste pour le plaisir, même si une expression régulière serait une solution plus compacte.

Pourquoi les expressions régulières sont-elles si controversées? Y a-t-il des malentendus répandus sur leur fonctionnement? Ou pourrait-on penser que les expressions régulières sont généralement lentes?

Je ne pense pas que les gens s'opposent aux expressions régulières parce qu'ils sont lents, mais plutôt parce qu'ils sont difficiles à lire et à écrire, ainsi que difficiles à comprendre. Bien qu'il existe certaines situations où les expressions régulières fournissent une solution efficace et compacte au problème, elles sont parfois mises en boîte dans des situations où il est préférable d'utiliser à la place une section de code facile à lire et maintenable.

Rendre les regexes maintenables

Une avancée majeure vers la démystification des modèles précédemment appelés «expressions régulières» est le /xdrapeau regex de Perl - parfois écrit (?x)lorsqu'il est intégré - qui permet les espaces blancs (saut de ligne, indentation) et les commentaires. Cela améliore considérablement la lisibilité et donc la maintenabilité. L'espace blanc permet un découpage cognitif, de sorte que vous pouvez voir quels groupes avec quoi.

Les modèles modernes prennent également en charge à la fois les références numériques relativement numérotées et nommées. Cela signifie que vous n'avez plus besoin de compter les groupes de capture pour comprendre que vous avez besoin de $4ou \7. Cela aide lors de la création de motifs qui peuvent être inclus dans d'autres motifs.

Voici un exemple de groupe de capture relativement numéroté:

$ dupword = qr {\ b (?: (\ w +) (?: \ s + \ g {-1}) +) \ b} xi;
$ quoted = qr {(["']) $ dupword \ 1} x;

Et voici un exemple de l'approche supérieure des captures nommées:

$dupword = qr{ \b (?: (?<word> \w+ ) (?: \s+ \k<word> )+ ) \b }xi;
$quoted  = qr{ (?<quote> ["'] ) $dupword  \g{quote} }x;

Regexes grammaticaux

Mieux encore , ces captures nommées peuvent être placées dans un (?(DEFINE)...)bloc, afin que vous puissiez séparer la déclaration de l'exécution des éléments nommés individuels de vos modèles. Cela les fait agir plutôt comme des sous-programmes dans le modèle.
Un bon exemple de ce genre de «regex grammatical» peut être trouvé dans cette réponse et celle-ci . Celles-ci ressemblent beaucoup plus à une déclaration grammaticale.

Comme ce dernier vous le rappelle:

… Assurez-vous de ne jamais écrire de modèles de bruit de ligne. Vous n'êtes pas obligé, et vous ne devriez pas. Aucun langage de programmation ne peut être maintenu et interdit les espaces blancs, les commentaires, les sous-programmes ou les identificateurs alphanumériques. Utilisez donc toutes ces choses dans vos modèles.

Cela ne peut pas être trop souligné. Bien sûr, si vous n'utilisez pas ces choses dans vos modèles, vous créerez souvent un cauchemar. Mais si vous les utilisez, vous n'en avez pas besoin.

Voici un autre exemple d'un modèle grammatical moderne, celui-ci pour l'analyse RFC 5322: utilisez 5.10.0;

$rfc5322 = qr{

   (?(DEFINE)

     (?<address>         (?&mailbox) | (?&group))
     (?<mailbox>         (?&name_addr) | (?&addr_spec))
     (?<name_addr>       (?&display_name)? (?&angle_addr))
     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ; (?&CFWS)?)
     (?<display_name>    (?&phrase))
     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)

     (?<addr_spec>       (?&local_part) \@ (?&domain))
     (?<local_part>      (?&dot_atom) | (?&quoted_string))
     (?<domain>          (?&dot_atom) | (?&domain_literal))
     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? (?&dcontent))* (?&FWS)?
                                   \] (?&CFWS)?)
     (?<dcontent>        (?&dtext) | (?&quoted_pair))
     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])

     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)

     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
     (?<quoted_pair>     \\ (?&text))

     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
     (?<qcontent>        (?&qtext) | (?&quoted_pair))
     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)

     (?<word>            (?&atom) | (?&quoted_string))
     (?<phrase>          (?&word)+)

     # Folding white space
     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
     (?<CFWS>            (?: (?&FWS)? (?&comment))*
                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))

     # No whitespace control
     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])

     (?<ALPHA>           [A-Za-z])
     (?<DIGIT>           [0-9])
     (?<CRLF>            \x0d \x0a)
     (?<DQUOTE>          ")
     (?<WSP>             [\x20\x09])
   )

   (?&address)

}x;

N'est-ce pas remarquable - et splendide? Vous pouvez prendre une grammaire de style BNF et la traduire directement en code sans perdre sa structure fondamentale!

Si les modèles grammaticaux modernes ne vous suffisent toujours pas, alors le brillant Regexp::Grammarsmodule de Damian Conway offre une syntaxe encore plus propre, avec un débogage supérieur également. Voici le même code pour analyser la refonte RFC 5322 dans un modèle de ce module:

#!/usr/bin/perl

use strict;
use warnings;
use 5.010;
use Data::Dumper "Dumper";

my $rfc5322 = do {
    use Regexp::Grammars;    # ...the magic is lexically scoped
    qr{

    # Keep the big stick handy, just in case...
    # <debug:on>

    # Match this...
    <address>

    # As defined by these...
    <token: address>         <mailbox> | <group>
    <token: mailbox>         <name_addr> | <addr_spec>
    <token: name_addr>       <display_name>? <angle_addr>
    <token: angle_addr>      <CFWS>? \< <addr_spec> \> <CFWS>?
    <token: group>           <display_name> : (?:<mailbox_list> | <CFWS>)? ; <CFWS>?
    <token: display_name>    <phrase>
    <token: mailbox_list>    <[mailbox]> ** (,)

    <token: addr_spec>       <local_part> \@ <domain>
    <token: local_part>      <dot_atom> | <quoted_string>
    <token: domain>          <dot_atom> | <domain_literal>
    <token: domain_literal>  <CFWS>? \[ (?: <FWS>? <[dcontent]>)* <FWS>?

    <token: dcontent>        <dtext> | <quoted_pair>
    <token: dtext>           <.NO_WS_CTL> | [\x21-\x5a\x5e-\x7e]

    <token: atext>           <.ALPHA> | <.DIGIT> | [!#\$%&'*+-/=?^_`{|}~]
    <token: atom>            <.CFWS>? <.atext>+ <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom_text>   <.atext>+ (?: \. <.atext>+)*

    <token: text>            [\x01-\x09\x0b\x0c\x0e-\x7f]
    <token: quoted_pair>     \\ <.text>

    <token: qtext>           <.NO_WS_CTL> | [\x21\x23-\x5b\x5d-\x7e]
    <token: qcontent>        <.qtext> | <.quoted_pair>
    <token: quoted_string>   <.CFWS>? <.DQUOTE> (?:<.FWS>? <.qcontent>)*
                             <.FWS>? <.DQUOTE> <.CFWS>?

    <token: word>            <.atom> | <.quoted_string>
    <token: phrase>          <.word>+

    # Folding white space
    <token: FWS>             (?: <.WSP>* <.CRLF>)? <.WSP>+
    <token: ctext>           <.NO_WS_CTL> | [\x21-\x27\x2a-\x5b\x5d-\x7e]
    <token: ccontent>        <.ctext> | <.quoted_pair> | <.comment>
    <token: comment>         \( (?: <.FWS>? <.ccontent>)* <.FWS>? \)
    <token: CFWS>            (?: <.FWS>? <.comment>)*
                             (?: (?:<.FWS>? <.comment>) | <.FWS>)

    # No whitespace control
    <token: NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f]

    <token: ALPHA>           [A-Za-z]
    <token: DIGIT>           [0-9]
    <token: CRLF>            \x0d \x0a
    <token: DQUOTE>          "
    <token: WSP>             [\x20\x09]

    }x;

};


while (my $input = <>) {
    if ($input =~ $rfc5322) {
        say Dumper \%/;       # ...the parse tree of any successful match
                              # appears in this punctuation variable
    }
}

Il y a beaucoup de bonnes choses dans la page de manuel de perlre , mais ces améliorations spectaculaires dans les fonctionnalités de conception regex fondamentales ne sont en aucun cas limitées à Perl seul. En effet, la page de manuel pcrepattern peut être plus facile à lire et couvre le même territoire.

Les modèles modernes n'ont presque rien en commun avec les choses primitives qui vous ont été enseignées dans votre classe d'automates finis.

Les regex sont un excellent outil, mais les gens pensent "Hé, quel excellent outil, je vais l'utiliser pour faire X!" où X est quelque chose pour lequel un autre outil est préférable (généralement un analyseur). C'est la norme à l'aide d'un marteau où vous avez besoin d'un problème de tournevis.

Presque tous ceux que je connais qui utilisent régulièrement des expressions régulières (jeu de mots) viennent d'un arrière-plan Unix où ils utilisent des outils qui traitent les RE comme des constructions de programmation de première classe, telles que grep, sed, awk et Perl. Comme il n'y a presque pas de surcharge syntaxique pour utiliser une expression régulière, leur productivité augmente considérablement lorsqu'ils le font.

En revanche, les programmeurs qui utilisent des langages dans lesquels les RE sont une bibliothèque externe ont tendance à ne pas considérer ce que les expressions régulières peuvent apporter à la table. Le "temps-coût" du programmeur est si élevé que soit a) les RE ne sont jamais apparus dans le cadre de leur formation, soit b) ils ne "pensent" pas en termes de RE et préfèrent se rabattre sur des schémas plus familiers.

Les expressions régulières vous permettent d'écrire une machine à états finis (FSM) personnalisée de manière compacte, pour traiter une chaîne d'entrée. Il y a au moins deux raisons pour lesquelles l'utilisation d'expressions régulières est difficile:

• Le développement de logiciels à l'ancienne implique beaucoup de planification, de modèles papier et de réflexion approfondie. Les expressions régulières s'intègrent très bien dans ce modèle, car pour écrire correctement une expression efficace, il faut beaucoup la regarder, visualiser les chemins du FSM.

  Les développeurs de logiciels modernes préfèrent de loin élaborer du code et utiliser un débogueur pour passer à travers l'exécution, pour voir si le code est correct. Les expressions régulières ne prennent pas très bien en charge ce style de travail. Une «exécution» d'une expression régulière est en fait une opération atomique. Il est difficile d'observer une exécution pas à pas dans un débogueur.

• Il est trop facile d'écrire une expression régulière qui accepte accidentellement plus de données que vous n'en pensez. La valeur d'une expression régulière ne correspond pas vraiment à une entrée valide, elle ne correspond pas à une entrée non valide . Les techniques pour faire des "tests négatifs" pour les expressions régulières ne sont pas très avancées, ou du moins pas largement utilisées.

  Cela va jusqu'à rendre les expressions régulières difficiles à lire. En regardant simplement une expression régulière, il faut beaucoup de concentration pour visualiser toutes les entrées possibles qui devraient être rejetées, mais qui sont acceptées par erreur. Avez-vous déjà essayé de déboguer le code d'expression régulière de quelqu'un d' autre ?

S'il y a une résistance à l'utilisation d'expressions régulières chez les développeurs de logiciels aujourd'hui, je pense que c'est principalement dû à ces deux facteurs.

Les gens ont tendance à penser que les expressions régulières sont difficiles; mais c'est parce qu'ils les utilisent mal. Écriture de lignes simples complexes sans aucun commentaire, indentation ou captures nommées. (Vous n'entamez pas votre expression SQL complexe sur une seule ligne, sans commentaires, indentation ou alias, n'est-ce pas?). Alors oui, pour beaucoup de gens, ça n'a pas de sens.

Cependant, si votre travail a quelque chose à voir avec l'analyse du texte (à peu près n'importe quelle application Web là-bas ...) et que vous ne connaissez pas l'expression régulière, vous craignez pour votre travail et vous perdez votre propre temps et celui de votre employeur. Il existe d' excellentes ressources pour tout vous apprendre à leur sujet, et bien plus encore.

Parce qu'ils n'ont pas l'outil d'apprentissage le plus populaire dans les IDE communément acceptés: il n'y a pas d'assistant Regex. Pas même la saisie semi-automatique. Vous devez coder le tout par vous-même.

" Expressions régulières: vous avez maintenant deux problèmes " est un excellent article de Jeff Atwood sur le sujet. Fondamentalement, les expressions régulières sont "dures"! Ils peuvent créer de nouveaux problèmes. Ils sont cependant efficaces.

Je ne pense pas qu'ils soient si controversés.

Je pense également que vous avez en quelque sorte répondu à votre propre question, car vous montrez à quel point il serait idiot de les utiliser partout ( tout n'est pas une langue régulière 2 ) ou d'éviter de les utiliser du tout. Vous, le programmeur, devez prendre une décision intelligente sur le moment où les expressions régulières aideront le code ou le blesseront. Face à une telle décision, deux choses importantes à garder à l'esprit sont la maintenabilité (qui implique la lisibilité) et l'extensibilité.

Pour ceux qui leur sont particulièrement opposés, je suppose qu'ils n'ont jamais appris à les utiliser correctement. Je pense que la plupart des gens qui passent seulement quelques heures avec un tutoriel décent les découvriront et deviendront couramment très rapidement. Voici ma suggestion par où commencer:

http://docs.python.org/howto/regex

Bien que cette page parle d'expressions régulières dans le contexte de Python, j'ai trouvé que les informations sont très applicables ailleurs. Il y a quelques éléments spécifiques à Python, mais je pense qu'ils sont clairement notés et faciles à retenir.

Les expressions régulières sont aux chaînes ce que les opérateurs arithmétiques sont aux nombres, et je ne les considérerais pas comme controversés. Je pense que même un activiste OO assez militant comme moi (qui aurait tendance à choisir d'autres objets plutôt que des cordes) aurait du mal à les rejeter.

Le problème est que les regex sont potentiellement si puissantes que vous pouvez faire des choses avec elles pour lesquelles vous devriez utiliser quelque chose de différent.

Un bon programmeur doit savoir où les utiliser et où non. L'exemple typique est l'analyse des langues non régulières (voir Décider si une langue est régulière ).

Je pense que vous ne pouvez pas vous tromper si vous vous limitez d'abord à de vraies expressions régulières (pas d'extensions). Certaines extensions peuvent vous faciliter la vie, mais si vous trouvez quelque chose de difficile à exprimer comme une vraie expression régulière, cela peut bien être une indication qu'une expression régulière n'est pas le bon outil.

Vous pourriez presque aussi bien demander pourquoi les goto sont controversés.

Fondamentalement, lorsque vous obtenez autant de pouvoir "évident", les gens sont susceptibles d'en abuser pour des situations pour lesquelles ils ne sont pas la meilleure option. Le nombre de personnes demandant à analyser des fichiers CSV ou XML ou HTML dans des expressions rationnelles, par exemple, m'étonne. Ce n'est pas le bon outil pour le travail. Mais certains utilisateurs insistent sur l'utilisation des expressions rationnelles de toute façon.

Personnellement, j'essaie de trouver ce juste milieu - utilisez des expressions régulières pour ce qu'elles sont bonnes et évitez-les lorsqu'elles ne sont pas optimales.

Notez que les expressions régulières peuvent toujours être utilisées pour analyser les CSV, XML, HTML, etc. Mais généralement pas dans une seule expression régulière.

Je ne pense pas que «controversé» soit le bon mot.

Mais j'ai vu des tonnes d'exemples où les gens disent "quelle est l'expression régulière dont j'ai besoin pour faire telle ou telle manipulation de chaîne?" qui sont des problèmes XY.

En d'autres termes, ils sont partis de l'hypothèse qu'un regex est ce dont ils ont besoin, mais ils seraient mieux avec un split (), une traduction comme tr /// de perl où les caractères sont substitués l'un à l'autre, ou juste un index ().

C'est un sujet intéressant.
De nombreux aficionados de regexp semblent confondre la concision de la formule avec l'efficacité.
En plus de cela, une expression rationnelle qui nécessite beaucoup de réflexion produit à son auteur une satisfaction massive qui la rend immédiatement légitime.

Mais ... les regexps sont si pratiques lorsque les performances ne sont pas un problème et que vous devez traiter rapidement une sortie de texte, en Perl par exemple. En outre, bien que les performances soient un problème, vous pouvez préférer ne pas essayer de battre la bibliothèque d'expressions régulières en utilisant un algorithme maison qui peut être bogué ou moins efficace.

En outre, il existe un certain nombre de raisons pour lesquelles les expressions rationnelles sont injustement critiquées, par exemple

• l'expression rationnelle n'est pas efficace, car la construction de celle du haut n'est pas évidente
• certains programmeurs "oublient" de ne compiler qu'une seule fois une expression rationnelle à utiliser plusieurs fois (comme un modèle statique en Java)
• certains programmeurs optent pour la stratégie d' essai et d'erreur - fonctionne encore moins avec les regexps!

Ce que je pense, c'est apprendre les regex et maintenir les regex en impopulaire, la plupart des développeurs sont paresseux ou la plupart d'entre eux s'appuient sur des bibliothèques externes pour faire l'analyse pour eux ... ils comptent sur Google pour la réponse et demandent même dans les forums pour le code complet de leur problème. Mais quand vient l'implémentation ou la modification / maintenance d'une expression régulière, ils échouent tout simplement.

Il y a un dicton populaire "Les amis ne laissent pas les amis utiliser Regex pour analyser le HTML"

Mais en ce qui me concerne, j'ai fait des analyseurs HTML complets en utilisant Regex et je trouve que les regex sont meilleurs pour analyser les chaînes html en termes de vitesse et de mémoire (si vous avez une idée de ce que vous devez accomplir :))

Les expressions régulières sont un mystère sérieux pour beaucoup de gens, y compris moi-même. Cela fonctionne très bien, mais c'est comme regarder une équation mathématique. Je suis heureux de signaler cependant que quelqu'un a finalement créé un emplacement consolidé de diverses fonctions d'expression régulière sur http://regexlib.com/ . Maintenant, si Microsoft ne créait qu'une classe d'expression régulière qui ferait automatiquement une grande partie des choses courantes comme l'élimination des lettres ou le filtrage des dates.

Je trouve parfois les expressions régulières inestimables. Quand j'ai besoin de faire des recherches "floues", et peut-être de les remplacer. Quand les données peuvent varier et avoir un certain caractère aléatoire. Cependant, lorsque je dois effectuer une recherche simple et remplacer, ou rechercher une chaîne, je n'utilise pas d'expressions régulières. Bien que je connaisse beaucoup de gens qui le font, ils l'utilisent pour tout. Telle est la controverse.

Si vous voulez mettre un clou dans le mur, n'utilisez pas de marteau. Oui, cela fonctionnera, mais au moment où vous obtenez le marteau, je pourrais mettre 20 punaises dans le mur.

Les expressions régulières doivent être utilisées pour ce pour quoi elles ont été conçues, et rien de moins.

Bien que je pense que les regex sont un outil essentiel, la chose la plus ennuyeuse à leur sujet est qu'il existe différentes implémentations. De légères différences de syntaxe, de modificateurs et, surtout, de «cupidité» peuvent rendre les choses vraiment chaotiques, nécessitant des essais et des erreurs et parfois des bugs déroutants.

Dans certains cas, je pense que vous DEVEZ les utiliser. Par exemple pour construire un lexer.

À mon avis, c'est le point de vue des personnes qui peuvent écrire des expressions rationnelles et des personnes qui ne le font pas (ou à peine). Personnellement je pense que c'est une bonne idée par exemple de valider la saisie d'un formulaire, que ce soit en javascript pour avertir l'utilisateur, ou en langage côté serveur.

Je pense que c'est une technique moins connue des programmeurs. Donc, il n'est pas largement accepté. Et si vous avez un responsable non technique pour revoir votre code ou revoir votre travail, alors une expression régulière est très mauvaise. Vous passerez des heures à écrire une expression régulière parfaite, et vous obtiendrez peu de notes pour le module en pensant qu'il / elle a écrit si peu de lignes de code. De plus, comme dit ailleurs, la lecture des expressions régulières est une tâche très difficile.

Les systèmes d'expression régulière décents tels que ceux utilisés dans lex et yacc pour la définition du compilateur sont bons, très utiles et propres. Dans ces systèmes, les types d'expression sont définis en fonction des autres. Ce sont les hideuses expressions régulières à une ligne géantes à bruit de ligne malformées et hideuses qui se trouvent couramment dans les codes perl et sed (etc.) qui sont `` controversées '' (ordures).

La meilleure utilisation valide et normale de l'expression régulière est pour la validation du format d'adresse e-mail.

C'est une bonne application.

J'ai utilisé d'innombrables expressions régulières comme ponctuelles dans TextPad pour masser des fichiers plats, créer des fichiers csv, créer des instructions d'insertion SQL et ce genre de choses.

Les expressions régulières bien écrites ne devraient pas être trop lentes. Habituellement, les alternatives, comme des tonnes d'appels à remplacer, sont des options beaucoup plus lentes. Autant le faire en un seul passage.

De nombreuses situations nécessitent des expressions exactement régulières et rien d'autre.

Le remplacement de caractères spéciaux non imprimables par des caractères inoffensifs est un autre bon usage.

Je peux bien sûr imaginer qu'il existe des bases de code qui surexploitent les expressions régulières au détriment de la maintenabilité. Je ne l'ai jamais vu moi-même. J'ai été en fait évité par les réviseurs de code pour ne pas utiliser suffisamment d'expressions régulières.