Выставка 1 , выставка 2 , думаю, вам не составит труда вспомнить другие примеры.
Дело в том, что если есть несколько способов решить проблему, программист PHP (я обычно просматриваю тег PHP в StackOverflow) запросит помощь в решении, включающем регулярные выражения.
Даже когда это будет менее экономично, даже если руководство по php предлагает ( ссылку ) использовать str_replace
вместо любой preg_*
или ereg_*
функцию, когда не требуются какие- либо необычные правила замены.
Кто-нибудь знает, почему это происходит?
Не поймите меня неправильно, некоторые из моих лучших друзей - регулярные выражения, и я не презираю Perl. Чего я не понимаю, так это того, почему не нужно искать альтернативы, даже когда перебор очевиден (регулярное выражение для переключения строк) или сложность кода возрастает экспоненциально (регулярное выражение для получения данных из html в PHP )
источник
Ответы:
Потому что на подсознательном уровне они чувствуют себя целой умной программой, которая может многого добиться сама по себе, в то же время охватывая и приспосабливаясь (мыслить шаблонами).
Вот почему люди сразу же верят, что регулярные выражения решат любую их задачу, основанную на тексте, почему-то не думая, что это может быть излишним, и не осознавая, что это может меня не устроить (анализируя языки с этим).
Крошечная вещь, содержащая магическую силу. Вы не можете сказать нет, не так ли?
источник
Когда единственный инструмент, который у вас есть, это регулярное выражение, каждая проблема выглядит
^((?>[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+)+|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$
источник
Я думаю это потому что:
источник
На ранних этапах моей карьеры (например, до PHP) я был гуру Perl, и одним из основных аспектов Perl gurudom является овладение регулярными выражениями.
В моей нынешней команде я буквально единственный из нас, кто ищет регулярные выражения перед другими (обычно более неприятными) инструментами. Похоже, что для остальной команды они чистая магия. Они подъедут к моему столу и попросят регулярное выражение, которое займет у меня буквально десять секунд, чтобы их собрать, а затем сдувать, когда это сработает. Я не знаю - я работал с ними так долго, это просто естественно на данный момент.
В отсутствие регулярных выражений у вас останется комбинация операторов управления потоком, заключающих в себе операторы strstr и strpos, что становится уродливым и трудным для запуска в вашей голове. Я бы предпочел создать одно изящное регулярное выражение, чем тридцать строк поиска висящей строки.
источник
Наоборот. Люди попугаи регулярные выражения являются злым мемом слишком часто ИМО. Очевидно, что preg_match используется
php
слишком часто, но менее очевидно, что часто это целесообразно (в PHP).Я бы зашел так далеко и предположил, что это еще одна микрооптимизация в php land для использования строковых функций. Есть много и много полезных, и они, как правило, лучший выбор. Но вы не должны избегать
preg_match
в пользу множестваstrpos
иif
цепей. Поскольку на практике оказывается, что libpcre часто быстрее, чем PHP может выполнить цикл поиска строковых альтернатив, напримерВ качестве недавнего примера я понял, что проверка строки в нижнем регистре:
Это более читабельно, чем:
И вы могли бы предположить, что первый должен быть быстрее, так как он полностью PHP. Но на самом деле регулярное выражение просматривает строку только один раз и может отменить отрицательное условие, как только обнаружит заглавную букву. Однако подход strtolower () просматривает строку дважды. Сначала strtolower () дублирует строку, перебирая каждую букву, сравнивая и заглавные буквы. Затем
==
перебирает оригинал и копию, сравнивая их еще раз.Так что это не очевидный случай. И чтобы быть объективным, первое часто быстрее, так как обычно вы просто сравниваете короткие строки. Но не следует слепо исходить из предположения, что строковые функции PHP всегда рекомендуются для регулярных выражений.
(Я испытываю желание добавить еще одну громкую речь о забавном ответе @ bobince относительно xhtml-регулярных выражений и о том, как это в последнее время часто связано очень бесполезным образом. А более объективные ответы ниже игнорируются.)
источник
/x
режиме, позволяющем выделить пробел для локтя когнитивного разделения, и для комментариев, объясняющих, почему что-то делается, должен, конечно, уложить свои уши. Но для реальных регулярных выражений разумной сложности вам необходимо рассмотреть возможность применения дизайна сверху вниз с помощью грамматических регулярных выражений . Как только вы увидели свет, вы никогда не вернетесь к/@#$^^@#$^&&*)@#/
.Регулярные выражения очень привлекательны, потому что они являются лучшим инструментом для синтаксического анализа обычного языка.
У них есть следующие преимущества:
N
за O (N
).Это делает их привлекательными для ситуаций, в которых они подходят, но люди могут использовать их в ситуациях, когда они не лучший инструмент, потому что они:
источник
vi
, вы ставите свою жизнь, которую я использую:%s/foo/bar/gc
на этом. Если это достаточно хорошо для редактора, это достаточно хорошо для сценария.Хм, я могу только догадываться. Возможно, некоторые люди сталкивались с тем, что 30 строк их кода были заменены регулярным выражением длиной 20 символов, поэтому для них было бы неправильным использовать что-либо другое вместо использования регулярных выражений.
источник
Это соответствует тому, как думают некоторые люди. Мне они не нравятся, но у меня есть друзья, которые, кажется, думают в регулярных выражениях. Я предполагаю, что часть их мозга, соответствующая шаблону, более открыта, чем формальная логика. :-)
источник
Я думаю, что повсеместное использование регулярных выражений связано с вездесущностью строк. Строка - это самая простая структура данных, первая, которую большинство из нас изучает. Поскольку весь наш код написан в символической форме, для программиста естественно подумать о моделировании чего-либо в символической форме. Но если наш язык программирования оказывает какое-либо сопротивление, когда мы пытаемся расширить его синтаксис для наших умных новых символических форм, они все заканчиваются между кавычками. Реляционная модель данных имеет SQL. Модель данных XML имеет XQuery. Но как насчет скромной строковой модели данных? Regex!
Буквально вчера я просматривал API для новой блестящей платформы Javascript, поддерживающей разработку игр на HTML5. У него есть декларативный механизм для описания основных подсистем, которые понадобятся вашей игре. Как определить эти функции? JSON? Свободное обозначение точки? Массив? Нет - строка, содержащая список имен элементов, разделенных запятыми и пробелами. Интересно, как он разбирает этот список ...?
источник
Потому что вы можете увидеть все это сразу. Увидев все это, легче работать, и это всегда приятно. Это похоже на причину, по которой многие программисты на C ++ все еще используют операторы printf-типа: это не типобезопасно (хотя gcc по крайней мере может проверять типы в операторах printf), и это не красиво, но мальчик компактен и удобен в использовании.
Если это достаточно простое регулярное выражение, то они часто являются наилучшим способом выполнения задач - их компактная форма и множество возможностей делают их идеальными для определенных задач. Проблема возникает, когда вы делаете регулярное выражение настолько сложным, что вы больше не можете его читать, или когда вы используете сложное регулярное выражение для выполнения чего-то, что может быть выполнено быстрее с помощью простых строковых операций.
Regex, как и любой другой мощный инструмент, должен использоваться в надлежащей модерации - не слишком много, не слишком мало. И если производительность не представляет большой проблемы, одно регулярное выражение иногда может быть быстрее написано и легче для отладки, чем ряд строковых операций.
источник
Хм, текущие ответы слишком сосредоточены на технических аспектах и на плюсах / минусах читабельности (что является важным моментом). Итак, позвольте мне попытаться перенести это немного больше в среду / сообщество PHP:
Но это как примечания стороны. Я считаю, что в любом случае это в основном воспринимаемые и технические причины, которые приводят к чрезмерному использованию и / или избеганию регулярных выражений в целом. Тем не менее, PHP и его пользовательская база имеют несколько свойств, которые его объединяют, и почему мы видим больше вопросов о SO [цитата нужна!], И они там «болезненно привлекательны».
источник
Мне нравятся регулярные выражения в целом, мне они легче читать / понимать, чем те 20 строк кода, которыми мне пришлось бы их заменить. Короткие регулярные выражения быстро читаются и понимаются, и их относительно легко поддерживать (если выражение изменяется, у вас есть только одна строка для изменения по сравнению с просмотром 20 строк кода для внесения изменений). Есть моменты, когда они используются не по назначению, но и многие другие.
Причина, по которой вы, вероятно, видите такое сильное злоупотребление ими, заключается в том, что вы просматриваете PHP-раздел StackOverFlow, поскольку, я уверен, вы знаете, что существует множество незрелых PHP-программистов.
источник
Почему регулярные выражения так болезненно привлекательны?
Они не. Они на самом деле ужасны, как ад. И непонятно. Это мерзость, которую нужно убить как можно скорее.
Теперь, как говорится, я возвращаюсь к отладке небольшого Perl-приложения. Не могу с этим поделать; к сожалению, иногда они остаются лучшим инструментом для работы.
источник
Человек - существо, использующее инструменты, а регулярные выражения - мощные инструменты. Хорошая метафора для регулярных выражений - кусочек мяса из гастронома. Если вы хотите тонкие кусочки индейки, солонины и т. Д., То это просто вещь. Однако вам нужны умелые руки, чтобы использовать его, потому что вы можете по-настоящему сильно порезаться им, и вы ничего не почувствуете, пока не увидите кровь. Под этим я подразумеваю то, что большая проблема с регулярными выражениями состоит в том, чтобы слегка их отключить, означает, что вы сопоставляете то, что не должны, или наоборот, и не узнаете, пока это не вызовет проблему в дальнейшем.
источник
Регулярные выражения очень привлекательны, потому что они обладают властью. Вы можете сделать очень сложную работу в очень мало символов.
Проблема заключается в том, что стандартная конструкция регулярного выражения не является полной по Тьюрингу, что означает, что существуют программы, которые вы просто не можете реализовать с помощью регулярного выражения, и люди не ЗНАЮ этого, когда их завлекает очевидная сила регулярных выражений.
Это - я полагаю - причина jwz-цитаты «теперь у них две проблемы».
Я предполагаю, что регулярные выражения Perl полны по Тьюрингу, но, видимо, они еще не были окончательно доказаны или опровергнуты.
источник
Потому что это эффективный способ программирования конечного автомата, который является мощным инструментом, когда он применяется. Это в основном свой собственный язык для программирования автоматов FSM, который полезен, если вы знаете язык, раздражает, если вы не знаете.
источник
В моем опыте регулярные выражения подобны древнему искусству, чему-то непонятному, некоторые люди обижаются на них, потому что они не могут понять колдовство и, возможно, потому, что никто не объяснит вам их. Я не слышал, чтобы университеты обучали их чему-то менее тривиальному, чем сопоставление по электронной почте. Тогда есть мистическая внутренняя работа этого, так как большинство людей не понимают их, они должны быть медленными . И заставить их работать нормально с первой попытки - это всегда вызов для новичков.
То же самое можно сказать о Perl, awk, Linux и всем, что не имеет блестящих кнопок или приятного цветного синтаксиса. Таким образом, это как дополнительная сложность для «тривиальных задач», просто бросить несколько циклов, разбиений, переключателя, немного магии и все, что-то, что может сработать. Но хорошо, если вы находитесь на другой стороне дороги, регулярные выражения - это красивые формочки для печенья, которые выглядят как сигнальные шумы без каких-либо неприятных циклов или дополнительных вещей для отладки. Я люблю их также за гибкость, которую они обеспечивают. Когда шаблон для соответствия меняется, вы просто меняете регулярное выражение, а не алгоритм или инструмент / что угодно, и это хорошо и снова работает. А так как они являются волшебной строкой, вы можете поместить ее вне исходного кода, если хотите. И еще одна вещь, которая заставляет меня думать о Perl: если вы пишете регулярное выражение длиной более 20 символов, вам кажется, что вы многого достигли, по крайней мере для меня, это так аккуратно и компактно. Я также ленивый программист, мне не нравится писать много кода с хорошими ссылками и комментариями и добавлять некоторые ошибки в микс.
источник