Можно ли рассматривать использование RegExp как накопление технического долга?

Question

[Talyutin]

Мы не рассматриваем единовременное (вроде Find & Replace) применение регулярных выражений, а применение в проекте для решения общих задач.

Краткое введение в понятие технического долга по ссылкам:
habrahabr.ru/post/119490/
techforum.mail.ru/report/64

Answer 1

[KEKSOV]

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

Лично у меня был такой опыт с RE — необходимо было организовать парсинг логов одной большой телефонной станции, началось все с использования sed и все было очень хорошо и быстро, пока не выяснилось, что эта железка в основной поток сообщений может асинхронно подбрасывать пакеты других сообщений. В итоге sed выражение разрослось до более чем ста строк и стало работать минут 10, само собой разобраться в нем мог только один человек. Когда мое терпение лопнуло, я сел и переписал все на C при помощи flex и bison, программа стала работать 10 секунд. Думаю, что это хороший пример того, как RE участвует в накоплении тех.долга

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

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

Comments

[TheHorse]

Свое решение может быть медленнее, чем простой regexp.

Answer 2

[KEKSOV]

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

Answer 3

[un1t]

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

У меня на одном из проектов нужно парсить разные xml файлы, причем файлы достаточно большие 200-600 Мб. Сначала я выбрал стандартное решение для питона — lxml.etree. Одно отлично работало, но оказалось, что не все файлы сформированы правильным образом. Там могут встречатся всякие ошибким типа незакрытих тегов и внутри могу быть какие-угодно кодировки, а не только та которая указана в xml-заголовке. Т.е. в одном файле может быть куча разных ошибок. Вобщем никаие стандартные решения не умеют обрабатывать все эти проблемы. Просле поиска готовых решений, я написал парсер на регулярках. Этому парсеру вообще пофиг на любые ошибки, он также может спокойно парсить любые битые файлы. К томуже оказалось, что такой парсер работает в 1.5 раза быстрее, чем парсер на lxml. В моем случае решение адекватно задаче.

Comments

[Talyutin]

Здесь, несомненно, классический пример технического долга.

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

Таким образом, данный пример вообще не может рассматриваться в контексте этого вопроса, как мне кажется.

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

[un1t]

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

[Talyutin]

Именно об этом я и говорил. В данном случае источник технического долга (уже существующего) — не вы. И как вы будете по нему «расплачиваться» — regexp'ом, предварительным приведением к корректному виду или как-то еще — не важно. Потому это и неважно в контексте вопроса…

Есть ли случаи, кроме уже описанных (валидация данных или костыли, как у вас), когда использование regexp не порождает технического долга.

Answer 4

[LionAlex]

Однажды у программиста появилась проблема и он захотел решить ее с помощью регулярных выражений. Тогда у программиста стало 2 проблемы.

Comments

[LionAlex]

нечитайпостсразупишикомментарий[x]

Answer 5

[egorinsk]

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

Или у вас есть какой-то более конкретный пример жутких последствий от использования regExp? А то иначе ситуация напоминает сказку про умную Эльзу.

Answer 6

[Wott]

О, чувствуется вам очень нравятся «волшебные правила», а вникать в суть желания немного. Тямы не хватает?

Регулярки — инструмент со вполне определенным кругом задач.
Технический долг — методика ускорения ближайших фаз проекта, за счет последующих.
Это абсолютно разные вещи.
Примерно также как «увлечение русским языком увеличивает долю ненормативной лексики в устной речи»
или «регистрация на хабре/вк/steam ухудшает производительность»
или тоньше «курение сокращает продолжительность жизни» :)