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

Question

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

Некоторые люди, сталкиваясь с проблема, подумай "Я знаю, я буду использовать регулярные выражения. "Теперь у них есть две проблемы. - Джейми Завински

И

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

Мои опасения (соответственно :)

• То, что инструмент может позволить решить проблему, используя сложное регулярное выражение, которое действительно не нуждается в этом. (См. Также этот вопрос ).

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

Должен ли я поощрять или не поощрять использование инструментов регулярных выражений, особенно в отношении создания нового кода? Оправданы ли мои опасения? Или я параноик?

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

Answer 9

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

regex-анализатор и regex-composer

github repo

Answer 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, чтобы убедиться, что он работает так, как они думают, что он работает, то это не сильно отличается от написания кода, который вы должны отлаживать.

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