Являются ли регулярные инструменты (например, RegexBuddy) хорошей идеей?

Ответ 1

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

Ответ 2

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

Лично я вижу такие вещи, как RegexBuddy и бесплатный Regex Coach в основном как инструменты обучения. Конечно, времена, когда они могут быть полезны для отладки или понимания существующих регулярных выражений, но, вообще говоря, если вы написали свое регулярное выражение с помощью инструмента, то его будет очень сложно поддерживать.

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

• Не используйте регулярное выражение, когда будет выполняться совпадение строк. Я часто вижу код, в котором люди используют регулярные выражения, чтобы соответствовать строковому регистру без учета. Просто нижний или верхний регистр строки и выполните стандартное сравнение строк.
• Не используйте регулярное выражение, чтобы увидеть, является ли строка одним из нескольких возможных значений. Это излишне сложно поддерживать. Вместо этого поместите возможные значения в массив, хеш (независимо от того, что предоставляет ваш язык) и проверьте строку на них.
• Записать тесты! Наличие набора тестов, специально предназначенных для вашего регулярного выражения, значительно облегчает процесс разработки, особенно если он смутно сложный. Кроме того, несколько тестов могут часто отвечать на многие вопросы, которые, по-видимому, будут иметь программисты-программисты по поводу вашего регулярного выражения.
• Постройте регулярное выражение из меньших частей. Если вам действительно нужно большое сложное регулярное выражение, создайте его из меньших тестируемых разделов. Это не только упрощает разработку (так как вы можете получить каждый отдельный раздел по отдельности), но также делает код более читабельным, гибким и позволяет тщательно комментировать.
• Создайте регулярное выражение в выделенной подпрограмме/функции/методе.. Это упрощает запись тестов для регулярного выражения (и только регулярного выражения). он также делает код, в котором ваше регулярное выражение используется более легким для чтения (красиво названный вызов функции значительно менее страшен, чем блок случайной пунктуации!). Отбрасывание огромных регулярных выражений в середину блока кода (где они не могут быть легко протестированы изолированно) чрезвычайно распространено и, как правило, очень легко избежать.

Ответ 3

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

Ответ 4

Я не уверен, почему так много неуверенности в отношении регулярного выражения.

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

Не беспокойтесь об этой цельной цитате "2 probs"; кажется, что это был взрыв на Perl (еще в 1997 году), а не регулярное выражение.

Ответ 9

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

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

Ответ 10

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

Таким образом, документация может помочь.

Это реальный тривиальный пример: таблица выглядит следующим образом (просто предложение)

Expression        Match     Reason
^                 Pos 0     Start of input
\s+               "      "  At least one space
(abs|floor|ceil)  ceil      One of "abs", "floor", or "ceil"
...

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

Однако, если они просто хотят отлаживать RE, чтобы убедиться, что это действует, поскольку они считают, что это действует, тогда это не сильно отличается от написания кода, который вы должны отлаживать.

Относительно.

Ответ 11

Несколько инструментов регулярных выражений (для Node/JS, PHP и Python), которые я создал (для некоторых других проектов). доступный онлайн, чтобы играть и экспериментировать.

regex-analyzer и regex-composer

github repo