regexes действительно удобны в сопровождении?

Действительно ли regexes являются способом сделать вещи? Это зависит от задачи.

Как со всеми вещами, программирующими, нет надежного права, или неправильно ответьте.

, Если regexp решает конкретную задачу быстро и просто, то это возможно лучше затем более подробное решение.

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

Regex не является ЕДИНСТВЕННЫМ способом сделать что-то. Можно сделать логически в коде все, что регулярное выражение может. Регулярные выражения всего

1. Быстры
2. Протестированный и Доказанный
3. Мощный

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

RegExs может быть очень удобен в сопровождении при использовании новых возможностей, представленных Perl 5.10. Функциями, к которым я обращаюсь, являются бэкпортированные функции от Perl 6.

Пример, скопированный непосредственно от perlretut.

Определение назвало шаблоны

, Некоторые регулярные выражения используют идентичные подшаблоны в нескольких местах. Начиная с Perl 5.10, возможно определить названный подшаблонами в разделе шаблона так, чтобы они могли быть призваны по имени где угодно в шаблоне. Этот синтаксический шаблон для этой группы определения (?(DEFINE)(?<name>pattern)...). Вставка именованного шаблона записана как (?&name).

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

/^
  (?&osg)\ * ( (?&int)(?&dec)? | (?&dec) )
        (?: [eE](?&osg)(?&int) )?
 $
 (?(DEFINE)
     (?<osg>[-+]?)         # optional sign
     (?<int>\d++)          # integer
     (?<dec>\.(?&int))     # decimal fraction
 )
/x

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

Замена regex с "C" или "C#" или "Java" или "Python" или "Perl" или "SQL" или "Ruby" или "awk" или... чем-либо, действительно, и Вы получаете тот же вопрос.

Regex является просто другим языком, , Huffman кодировал , чтобы быть эффективным при сопоставлении строк. Точно так же, как Java, Perl, PHP или особенно SQL, каждый язык имеет достоинства и недостатки, и необходимо знать язык, который Вы пишете в том, когда Вы пишете это (или поддерживаете его) иметь любую надежду на то, чтобы быть продуктивным.

Редактирование: Mike, regex's является Huffman, кодированный в этом, общие вещи сделать короче, чем, чем более редкие вещи. Литеральные соответствия текста обычно являются отдельным символом (тот, которому Вы хотите соответствовать). Специальные символы существуют - общие коротки. Специальные конструкции, такой как (? :) длиннее. Это не то же самое, которое было бы распространено в языках общего назначения как Perl, C++, и т.д., таким образом, Кодирование методом Хаффмана было предназначено для этой специализации.

Комплекс regexes "выпустил-забыл" для меня. Запишите это, протестируйте его, и когда это работает, запишите комментарий, что это делает и мы в порядке.

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

знакомые Звуки? Это более или менее верно для любого кода. Вы не хотите иметь очень длинные методы, Вы не хотите иметь очень длинные классы, и Вы не хотите иметь очень длинные регулярные выражения, хотя методы и классы намного легче осуществить рефакторинг. Но в сущности, это - то же понятие.

На волшебство только походит, если Вы не понимаете regex. Любое количество небольших изменений в производственном коде может вызвать основные проблемы так, чтобы не было серьезное основание, по-моему, не использовать regex's. Полное тестирование должно указать на любые проблемы.

Я не знаю, какой язык Вы используете, но Perl - например - поддерживает эти x флаг, таким образом, пробелы проигнорированы в regexes, если не оставлено, таким образом, можно повредить его в несколько строк и прокомментировать, что все встраивает:

$foo =~ m{
    (some-thing)          # matches something
    \s*                   # matches any amount of spaces
    (match another thing) # matches something else
}x;

Это помогает созданию длинный более читаемый regexes.

Обязательный.

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

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

Два примера PHP PCRE (специфические особенности, или конкретное использование не важны):

1)
  $dktpat = '/^[^a-z0-9]*'. // skip any initial non-digits
    '([a-z0-9]:)?'. // division within the district
    '(\d+)'. // year
    '((-)|-?([a-z][a-z])-?)'. // type of court if any - cv, bk, etc.
    '(\d+)'. // docket sequence number
    '[^0-9]*$/i'; // ignore anything after the sequence number
  if (preg_match($dktpat,$DocketID,$m)) {

2)
    $pat= array (
      'Row'        => '\s*(\d*)',
      'Parties'    => '(.*)',
      'CourtID'    => '<a[^>]*>([a-z]*)</a>',
      'CaseNo'     => '<a[^>]*>([a-z0-9:\-]*)</a>',
      'FirstFiled' => '([0-9\/]*)',
      'NOS'        => '(\d*)',
      'CaseClosed' => '([0-9\/]*)',
      'CaseTitle'  => '(.*)',
    );
    // wrap terms in table syntax
    $pat = '#<tr>(<td[^>]*>'.
      implode('</td>)(</tr><tr>)?(<td[^>]*>',$pat).
      '</td>)</tr>#iUx';
    if (preg_match_all ($pat,$this->DocketText,$matches, PREG_PATTERN_ORDER))

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

Я всегда приближался к этой проблеме как к проблеме стандартного блока.

Вы только пишете приблизительно 3 000 символов regex и надеетесь на лучшее. Вы пишете набор маленьких блоков, которые Вы добавляете вместе.

, Например, для соответствия URI у Вас есть протокол, полномочия, субдомен, домен, tld, путь, аргументы (по крайней мере). И некоторые из них являются дополнительными!

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

Я обычно иду вплоть до записи файла спецификации сканера. Сканер, или "генератор сканера" является по существу оптимизированным текстовым синтаксическим анализатором. Так как я обычно работаю с Java, мой предпочтительный метод является JFlex ( http://www.jflex.de ), но существует также Закон, YACC и несколько других.

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

Когда дело доходит до кода у меня есть файл спецификации, содержащий всю логику синтаксического анализа. Я выполняю его через инструмент генератора сканера выбора генерировать исходный код на предпочтительном языке. Затем я просто переношу все это в функцию синтаксического анализатора или какой-то класс. Эта абстракция затем помогает управлять всей логикой регулярного выражения, и это - очень хорошая производительность. Конечно, это - излишество, если Вы работаете со всего одним или двумя regexps, и легко требуется по крайней мере 2-3 дня для изучения то что, черт возьми, продолжается, но если Вы когда-нибудь работаете с, скажем, 5 или 6 или 30 из них, это становится действительно хорошей функцией, и реализующий логику синтаксического анализа начинает только занимать минуты, и они остаются легкими поддержать и легкий к документу.

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

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

У меня есть политика полного комментария нетривиального regexes. Это означает описывать и выравнивать по ширине каждый атом, который не соответствует себе. Некоторые языки (Python, для одного) предлагают "подробные" regexes, которые игнорируют пробел и позволяют комментарии; используйте это, когда это возможно. Иначе пойдите атом атомом в комментарии выше regex.

Regex упоминался как язык программирования "только для записи" наверняка. Однако я не думаю, что означает, что необходимо избежать их. Я просто думаю, что необходимо прокомментировать ад из их намерения. Я обычно - не большой поклонник комментариев, которые объясняют , что делает строка, я могу прочитать код для этого, но Regexs являются исключением. Прокомментируйте все!

Существует много возможностей сделать RegEx более удобным в сопровождении. В конце это - просто техника (хороший?) программист должен изучить когда дело доходит до главного (или иногда даже незначительный) изменения. Когда не было некоторого действительно хорошего pro's, никто не обеспокоится ими из-за их сложного синтаксиса. Но они быстры, компактны и очень гибки в выполнении их задания.

Для Людей.NET мог быть" Linq к RegEx" библиотека, хуже взгляд или" Читаемая Библиотека Регулярных выражений ". Это делает их более легкими поддержать и все же легче записать. Я использовал их обоих в собственных проектах, я знал исходный код HTML, который я проанализировал с ними, мог измениться в любое время.

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

известная кавычка о regexes:

"Некоторые люди, сталкиваясь с проблемой, думают, что “I знают, я буду использовать регулярные выражения. ” Теперь у них есть две проблемы". - Jamie Zawinski

, Когда я действительно использую regexes, я нахожу, что они удобны в сопровождении, но они используются в особых случаях. Обычно существует лучшее, non-regex метод для того, чтобы сделать почти все.

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

Некоторые люди уже упоминали флаг «x» в Perl, который немного помогает, но не сильно.

Мне очень нравятся регулярные выражения, но не синтаксис. Было бы неплохо иметь возможность построить регулярное выражение из понятных, значимых имен методов. Например, вместо этого кода C #:

foreach (var match in Regex.Matches(input, @"-?(?<number>\d+)"))
{
    Console.WriteLine(match.Groups["number"].Value);
}

у вас может быть что-то более подробное, но более читаемое и удобное в обслуживании:

int number = 0;
Regex r = Regex.Char('-').Optional().Then(
    Regex.Digit().OneOrMore().Capture(c => number = int.Parse(c))
);
foreach (var match in r.Matches(input))
{
    Console.WriteLine(number);
}

Это всего лишь небольшая идея; Я знаю, что есть и другие, не связанные с этим проблемы с ремонтопригодностью (хотя я бы сказал, что их меньше и меньше). Дополнительным преимуществом этого является проверка во время компиляции.

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

instead of:   -?(?<number>\d+)
could have:   ("-" or "") + (number = digit * [1..])

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

Я действительно не знаю, почему существует столько возражений против переосмысления синтаксиса регулярных выражений, даже когда переосмысляются целые языки программирования (например, Perl 6 или когда C # был новым).Более того, приведенная выше очень многословная идея не несовместима даже со «старыми» регулярными выражениями; API можно легко реализовать как тот, который под капотом строит регулярное выражение старого стиля.