Должен ли я избегать регулярных выражений? [закрыто]

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

Обычно я слышу два аргумента против регулярных выражений: 1) Они неэффективны в вычислительном отношении, и 2) Их трудно понять.

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

1) Это может быть правдой в академическом смысле. Сложное выражение может дублировать само себя, может многократно. Но действительно ли это важно? Сколько миллионов вычислений в секунду может выполнять серверный процессор в наши дни? Я имел дело с некоторыми сумасшедшими выражениями, и я никогда не видел, чтобы регулярное выражение было узким местом. Безусловно, это взаимодействие с БД, за которым следует пропускная способность.

2) Тяжело около недели. Самое сложное регулярное выражение не сложнее HTML - это просто проблема знакомства. Если бы вам понадобился HTML раз в 3 месяца, вы бы каждый раз получали его на 100%? Работайте с ними ежедневно, и они так же ясны, как и любой другой синтаксис языка.

Я пишу программное обеспечение для проверки. РЕГЭКСП ' s - вторая натура. В каждой пятой строке кода есть регулярное выражение, и хоть убей, я не могу понять, почему люди так много думают о них. Я никогда не видел, чтобы регулярное выражение замедляло обработку, и я видел, как даже самые скучные «программисты» подбирали синтаксис.

Регулярные выражения мощны, эффективны и полезны. Зачем их избегать?

I'd agree that regular expressions are sometimes used inappropriately. Certainly for very simple cases like what you're describing, but also for cases where a more powerful parser is needed.

One consideration is that sometimes you have a condition that needs to do something simple like test for presence of a question mark character. But it's often true that the condition becomes more complex. For example, to find a question mark character that isn't preceded by a space or beginning-of-line, and isn't followed by an alphanumeric character. Or the character may be either a question mark or the Spanish "¿" (which may appear at the start of a word). You get the idea.

If conditions are expected to evolve into something that's less simple to do with a plain call to String.contains("?"), then it could be easier to code it using a very simple regular expression from the start.

Я часто использую регулярное выражение в своей среде IDE для быстрого исправления кода. Попробуйте сделать следующее без регулярного выражения:

glVector3f (-1.0f, 1.0f, 1.0f); -> glVector3f (center.x - 1.0f, center.y + 1.0f, center.z + 1.0f);

Без регулярного выражения это проблема, но С регулярным выражением ...

s/glVector3f\((.*?),(.*?),(.*?)\)/glVector3f(point.x+$1,point.y+$2,point.z+$3)/g

Замечательно.

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

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

Это не значит, что ими не злоупотребляют. Единственный случай, когда string.match (/ \? /) Лучше, чем string.contains ('?'), - это если он значительно более читается с окружающим кодом или если вы знаете, что .contains все равно реализован с помощью регулярных выражений

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

Это система для решения проблем синтаксического анализа.

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

Есть очень веская причина использовать регулярные выражения в языках сценариев (таких как Ruby, Python, Perl, JavaScript и Lua): анализ строки с тщательно оптимизированным регулярным выражением выполняется быстрее, чем эквивалент настраиваемый цикл while, который просматривает строку посимвольно. Для скомпилированных языков (таких как C и C ++, а также C # и Java большую часть времени) обычно верно обратное: пользовательский цикл while выполняется быстрее.

Еще одна причина, по которой регулярные выражения так популярны: они выражают намерение чрезвычайно компактно: однострочное регулярное выражение может делать столько же, сколько и цикл while из 10 или 20 строк.

По моему мнению, люди довольно часто ими злоупотребляют (я неоднократно обсуждал это на SO).

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

Достаточно взглянуть на такой пример, как регистрационный номер автомобиля в Западной Австралии. RE будет

re.match("[1-9] [A-Z]{3} [0-9]{3}")

, в то время как код для проверки этого будет значительно длиннее, либо в простой 9-if-инструкции, либо в немного лучшей версии цикла.

Я почти никогда не использую сложные RE в своем коде, потому что:

• Я знаю, как работают механизмы RE, и я могу использовать знания предметной области для кодирования более быстрых решений (этот вариант с 9 if почти наверняка будет быстрее, чем однократный цикл компиляции / выполнения RE); и
• Я считаю код более читаемым, если он логически разбит и прокомментирован. Это н' С большинством RE легко (хотя я видел такой, который позволяет встроенные комментарии).

Я видел, как люди предлагают использовать RE для извлечения подстроки фиксированного размера в фиксированном месте. Почему эти люди просто не используют substring () , мне непонятно. Лично я считаю, что они просто пытаются показать, насколько они умны (но это редко срабатывает).

Перегиб? Нет

Используется недостаточно правильно? Да

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

С другой стороны, я уверен, что программисты C и C ++ будут для по большей части сначала изучите другие параметры, поскольку они не встроены в язык.

«Когда у вас есть молоток, все выглядит как гвоздь»

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

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

Перегиб? Нет. Они очень мощные и гибкие.

Злоупотребляли? Абсолютно. В частности, когда дело доходит до синтаксического анализа HTML (который здесь часто встречается).

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

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

Но рукописный код почти всегда будет быстрее. Хорошим примером этого является Помещение char в строку java для каждых N символов . Решение с регулярным выражением короче, но имеет некоторые проблемы, которых нет в ручном цикле.

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

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

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

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

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

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

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

Серьезно, я не понимаю. Это такой же инструмент, как и любой другой. Если вам нужен простой веб-сайт с некоторым текстом, вам не нужен PHP / ASP.NET / STG44. Тем не менее, никаких дискуссий о том, следует ли избегать чего-либо из этого. Как странно.

По моему опыту, RegEx, вероятно, самый полезный инструмент, с которым я когда-либо сталкивался как разработчик. Это самый полезный инструмент, когда речь идет о проблеме безопасности №1: синтаксическом анализе пользовательского ввода. Я сэкономил часы, если не дни написания кода и создания потенциально ошибочного (читай: дрянного) кода.

С современными процессорами я не вижу, в чем проблема производительности. Я' m вполне готов пожертвовать некоторыми циклами ради некоторого качества и безопасности. (Это не всегда так, но я думаю, что такие случаи редки.)

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

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

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

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

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

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

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

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

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

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

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

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

По памяти, в Википедии есть достойная статья о регулярных выражениях и лежащих в их основе алгоритмах.