Почему регулярные выражения так противоречивы? [закрыто]

При изучении регулярных выражений (также известных как RegEx-es), есть много людей, которые видят регулярные выражения как Святой Грааль. То, что выглядит так сложно - просто должно быть ответом на любой вопрос. Они склонны думать, что каждая проблема разрешима с помощью регулярных выражений.

С другой стороны, есть также много людей, которые пытаются избежать регулярных выражений любой ценой. Они пытаются найти способ обойти регулярные выражения и принять дополнительное кодирование только ради этого, даже если регулярные выражения будут более компактным решением.

Почему регулярные выражения считаются такими противоречивыми? Есть ли распространенные недоразумения о том, как они работают? Или может быть распространено мнение, что регулярные выражения, как правило, медленные?

Я не думаю, что люди возражают против регулярных выражений, потому что они медленные, а скорее потому, что их трудно читать и писать, а также сложно понять, как правильно. Хотя в некоторых ситуациях регулярные выражения обеспечивают эффективное и компактное решение проблемы, они иногда включаются в ситуации, когда вместо этого лучше использовать легко читаемый, поддерживаемый раздел кода.

Создание регулярных выражений

Основным достижением в направлении демистификации шаблонов, ранее называемых «регулярными выражениями», является /xфлаг регулярного выражения Perl, иногда записываемый (?x)при внедрении, который позволяет использовать пробелы (разрыв строки, отступ) и комментарии. Это серьезно улучшает удобочитаемость и, следовательно, удобство обслуживания. Пустое пространство учитывает когнитивные фрагменты, так что вы можете видеть, какие группы с чем.

Современные шаблоны также теперь поддерживают как относительно нумерованные, так и именованные обратные ссылки. Это означает, что вам больше не нужно считать группы захвата, чтобы выяснить, что вам нужно $4или \7. Это помогает при создании шаблонов, которые могут быть включены в другие шаблоны.

Вот пример относительно пронумерованной группы захвата:

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

И вот пример превосходного подхода именованных захватов:

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

Грамматические регулярные выражения

Лучше всего , что эти именованные захваты могут быть помещены в (?(DEFINE)...)блок, так что вы можете отделить объявление от выполнения отдельных именованных элементов ваших шаблонов. Это заставляет их действовать скорее как подпрограммы в шаблоне.
Хороший пример такого рода «грамматического регулярного выражения» можно найти в этом и этом ответе . Это больше похоже на грамматическую декларацию.

Как последнее напоминает вам:

… Следите за тем, чтобы никогда не писать шаблоны линейного шума. Вам не нужно, и вы не должны. Нельзя поддерживать язык программирования, который запрещает пробелы, комментарии, подпрограммы или буквенно-цифровые идентификаторы. Так что используйте все эти вещи в своих шаблонах.

Это нельзя переоценить. Конечно, если вы не используете эти вещи в своих шаблонах, вы часто будете создавать кошмар. Но если вы делаете их использовать, хотя, вам не нужно.

Вот еще один пример современного грамматического шаблона, этот для анализа RFC 5322: используйте 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;

Разве это не замечательно - и великолепно? Вы можете взять грамматику в стиле BNF и перевести ее непосредственно в код, не теряя своей фундаментальной структуры!

Если вам по- прежнему недостаточно современных грамматических шаблонов , то великолепный Regexp::Grammarsмодуль Дамиана Конвея предлагает еще более чистый синтаксис и превосходную отладку. Вот тот же код для разбора RFC 5322, преобразованного в шаблон из этого модуля:

#!/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
    }
}

Там очень много хороших вещей в perlre страница руководства , но эти значительные улучшения в основных регулярных выражений конструктивных особенностей отнюдь не ограничивается Perl в одиночку. Действительно pcrepattern страница руководства может быть легче читать, и охватывает ту же территорию.

Современные шаблоны почти не имеют ничего общего с примитивными вещами, которым вас учили в вашем классе конечных автоматов.

Регулярные выражения - отличный инструмент, но люди думают: «Эй, какой замечательный инструмент, я буду использовать его, чтобы делать X!» где X - это то, для чего лучше использовать другой инструмент (обычно это парсер). Это стандартное использование молотка, когда вам нужна проблема с отверткой.

Почти все, кого я знаю, кто регулярно использует регулярные выражения (предназначено для каламбура), имеют опыт работы в Unix, где они используют инструменты, которые рассматривают RE как первоклассные программные конструкции, такие как grep, sed, awk и Perl. Поскольку использование регулярных выражений почти не приводит к синтаксическим издержкам, их производительность значительно возрастает.

Напротив, программисты, которые используют языки, в которых RE являются внешней библиотекой, обычно не учитывают, что регулярные выражения могут принести в таблицу. «Затраты времени» программиста настолько высоки, что либо а) RE никогда не появлялись как часть их обучения, либо б) они не «думали» с точки зрения RE и предпочитали прибегать к более знакомым шаблонам.

Регулярные выражения позволяют вам компактно написать собственный конечный автомат (FSM), чтобы обработать строку ввода. Есть по крайней мере две причины, почему использование регулярных выражений сложно:

• Разработка программного обеспечения старой школы требует много планирования, бумажных моделей и тщательного обдумывания. Регулярные выражения очень хорошо вписываются в эту модель, потому что для правильного написания эффективного выражения нужно много на него смотреть, визуализируя пути FSM.

  Современные разработчики программного обеспечения предпочитают разрабатывать код и использовать отладчик для пошагового выполнения и проверки правильности кода. Регулярные выражения не очень хорошо поддерживают этот стиль работы. Один «прогон» регулярного выражения - фактически атомарная операция. Трудно наблюдать пошаговое выполнение в отладчике.

• Слишком легко написать регулярное выражение, которое случайно принимает больше входных данных, чем вы предполагаете. Значение регулярного выражения на самом деле не соответствует допустимому вводу, оно не должно соответствовать неверному вводу . Методы выполнения «отрицательных тестов» для регулярных выражений не очень продвинуты или, по крайней мере, широко не используются.

  Это приводит к тому, что регулярные выражения трудно читать. Просто глядя на регулярное выражение, требуется большая концентрация, чтобы визуализировать все возможные входные данные, которые должны быть отклонены, но ошибочно приняты. Вы когда-нибудь пытались отлаживать чужой код регулярного выражения?

Если сегодня среди разработчиков программного обеспечения есть сопротивление использованию регулярных выражений, я думаю, что это в основном из-за этих двух факторов.

Люди склонны считать регулярные выражения сложными; но это потому, что они используют их неправильно. Написание сложных однострочников без каких-либо комментариев, отступов или именованных снимков. (Вы не помещаете свое сложное выражение SQL в одну строку, без комментариев, отступов или псевдонимов, не так ли?). Так что да, для многих людей это не имеет смысла.

Однако, если ваша работа имеет какое-либо отношение к синтаксическому анализу текста (примерно, любого веб-приложения) ... и вы не знаете регулярных выражений, вы сосете на своей работе и тратите свое время и время работодатель. Есть отличные ресурсы , чтобы рассказать вам все о них, что вам когда-либо нужно знать, и многое другое.

Потому что им не хватает самого популярного инструмента обучения в общепринятых IDE: Regex Wizard не существует. Даже автозаполнение. Вы должны все это кодировать самостоятельно.

« Регулярные выражения: теперь у вас две проблемы » - отличная статья Джеффа Этвуда по этому вопросу. В основном, регулярные выражения являются «сложными»! Они могут создавать новые проблемы. Они эффективны, однако.

Я не думаю, что они такие противоречивые.

Я также думаю, что вы как бы ответили на свой вопрос, потому что вы указываете, как глупо было бы использовать их повсюду ( не все - это обычный язык 2 ) или вообще избегать их использования. Вы, программист, должны принять разумное решение о том, когда регулярные выражения помогут коду или повредят его. Столкнувшись с таким решением, следует помнить о двух важных моментах: удобство обслуживания (что подразумевает читабельность) и расширяемость.

Для тех, кто особенно против них, я предполагаю, что они никогда не учились использовать их должным образом. Я думаю, что большинство людей, которые проводят всего несколько часов с приличным учебным пособием, поймут их и очень быстро овладеют. Вот мое предложение о том, с чего начать:

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

Хотя на этой странице говорится о регулярных выражениях в контексте Python, я обнаружил, что эта информация очень применима в других местах. Есть несколько вещей, которые специфичны для Python, но я считаю, что они четко отмечены и легко запоминаются.

Регулярные выражения представляют собой строки, арифметические операторы - числам, и я не считаю их спорными. Я думаю, что даже такой воинствующий активист ОО, как я (который склонен выбирать другие объекты, а не строки), будет трудно отказаться от них.

Проблема в том, что регулярные выражения потенциально настолько мощны, что вы можете делать с ними что-то, что вы должны использовать что-то другое для.

Хороший программист должен знать, где их использовать, а где нет. Типичным примером является синтаксический анализ нерегулярных языков (см. « Решение о том, является ли язык регулярным ).

Я думаю, что вы не ошибетесь, если сначала ограничитесь реальными регулярными выражениями (без расширений). Некоторые расширения могут сделать вашу жизнь немного проще, но если вам трудно выразить что-то как реальное регулярное выражение, это может быть признаком того, что регулярное выражение не является правильным инструментом.

Вы почти можете также спросить о том, почему goto являются спорными.

По сути, когда вы получаете так много «очевидной» силы, люди склонны злоупотреблять ими в ситуациях, для которых они не являются лучшим вариантом. Например, меня поражает количество людей, которые просят разобрать CSV, XML или HTML в регулярных выражениях. Это неподходящий инструмент для работы. Но некоторые пользователи все равно настаивают на использовании регулярных выражений.

Лично я пытаюсь найти эту счастливую среду - использовать регулярные выражения для того, для чего они хороши, и избегать их, когда они не оптимальны.

Обратите внимание, что регулярные выражения по-прежнему могут использоваться для анализа CSV, XML, HTML и т. Д. Но обычно не в одном регулярном выражении.

Я не думаю, что слово «спорный» является правильным.

Но я видел множество примеров, когда люди говорят: «Какое регулярное выражение мне нужно, чтобы делать такие-то и такие-то манипуляции со строками?» которые являются проблемами XY.

Другими словами, они начали с предположения, что регулярное выражение - это то, что им нужно, но им лучше воспользоваться split (), переводом, подобным tr /// в perl, где символы заменяют друг друга, или просто индекс ().

Это интересная тема.
Многие поклонники регулярных выражений , похоже, путают краткость формулы с эффективностью.
Кроме того, регулярное выражение, требующее много размышлений, дает его автору огромное удовлетворение, которое сразу делает его законным.

Но ... регулярные выражения так удобны, когда производительность не является проблемой, и вам нужно быстро справиться с выводом текста, например, в Perl. Кроме того, хотя производительность является проблемой, можно не пытаться побить библиотеку регулярных выражений, используя самодельный алгоритм, который может содержать ошибки или быть менее эффективным.

Кроме того, существует ряд причин, по которым регулярные выражения подвергаются несправедливой критике, например,

• регулярное выражение неэффективно, потому что построение верхнего не очевидно
• некоторые программисты "забывают" скомпилировать только один раз регулярное выражение для многократного использования (например, статический шаблон в Java)
• некоторые программисты придерживаются стратегии проб и ошибок - с регулярными выражениями работает еще меньше!

Я думаю, что изучение Regex и поддержка регулярных выражений делает его непопулярным, большинство разработчиков ленивы, или большинство из них полагаются на внешние библиотеки, чтобы выполнить их анализ ... они полагаются на Google для ответа и даже спрашивают на форумах полный код для их проблемы. Но когда дело доходит до реализации или изменения / поддержания регулярного выражения, они просто терпят неудачу.

Существует популярная поговорка «Друзья не позволяют друзьям использовать Regex для анализа HTML»

Но что касается меня, я сделал полные HTML-парсеры с использованием Regex, и я считаю, что regex лучше разбирает html-строки как по скорости, так и по памяти (если у вас есть идея, чего вы хотите достичь :))

Регулярные выражения являются серьезной загадкой для многих людей, включая меня. Это прекрасно работает, но это похоже на математическое уравнение. Я рад сообщить, что кто-то наконец-то создал сводное расположение различных функций регулярных выражений на http://regexlib.com/ . Теперь, если Microsoft создаст только класс регулярных выражений, который автоматически сделает большую часть общих вещей, таких как удаление писем или фильтрация дат.

Я нахожу регулярные выражения неоценимыми время от времени. Когда мне нужно сделать несколько «нечетких» поисков и, возможно, заменить. Когда данные могут отличаться и иметь определенную случайность. Однако, когда мне нужно выполнить простой поиск и заменить или проверить строку, я не использую регулярные выражения. Хотя я знаю многих людей, которые делают это, они используют это для всего. Это противоречие.

Если вы хотите положить гвоздь в стену, не используйте молоток. Да, это сработает, но к тому времени, как ты получишь молоток, я смогу положить 20 гвоздей в стену.

Регулярные выражения должны использоваться для того, для чего они были разработаны, и не меньше.

Хотя я думаю, что регулярные выражения являются важным инструментом, наиболее раздражающим в них является то, что существуют разные реализации. Небольшие различия в синтаксисе, модификаторах и, особенно, «жадности» могут сделать вещи действительно хаотичными, требуя проб и ошибок и иногда вызывая удивительные ошибки.

В некоторых случаях я думаю, что вы должны их использовать. Например, чтобы построить лексер.

На мой взгляд, это точка зрения людей, которые могут писать регулярные выражения, и людей, которые не (или вряд ли). Я лично считаю, что это хорошая идея, например, для проверки правильности ввода формы, будь то в JavaScript, чтобы предупредить пользователя, или на стороне сервера.

Я думаю, что это менее известная техника среди программистов. Таким образом, нет широкого признания для этого. И если у вас есть нетехнический менеджер для проверки вашего кода или проверки вашей работы, то регулярное выражение очень плохое. Вы потратите часы на написание идеального регулярного выражения, и вы получите несколько баллов за модуль, думая, что он написал так мало строк кода. Также, как сказано в другом месте, чтение регулярных выражений является очень сложной задачей.

Приличные системы регулярных выражений, такие как используемые в lex и yacc для определения компилятора, хороши, очень полезны и чисты. В этих системах типы выражений определяются в терминах других. Это отвратительные искаженные нечитаемые гигантские однострочные регулярные выражения с линейным шумом, которые обычно встречаются в кодах perl и sed (и т. Д.), Являются «спорными» (мусор).

Лучшее действительное и нормальное использование для регулярных выражений - для проверки формата адреса электронной почты.

Это хорошее применение.

Я использовал бесчисленное количество раз регулярные выражения в качестве одноразовых в TextPad для массажа плоских файлов, создания CSV-файлов, создания операторов вставки SQL и тому подобного.

Хорошо написанные регулярные выражения не должны быть слишком медленными. Обычно альтернативы, такие как тонны обращений к Replace, гораздо медленнее. Можно сделать это за один проход.

Многие ситуации требуют именно регулярных выражений и ничего больше.

Замена специальных непечатаемых символов безобидными символами - еще одно хорошее применение.

Конечно, я могу себе представить, что есть некоторые кодовые базы, которые используют регулярные выражения в ущерб удобству сопровождения. Я никогда не видел это сам. Я на самом деле сторонился рецензентов за то, что не использовал регулярные выражения.