Регулярные выражения стоят хлопот?

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

Лично я бы выбрал регулярное выражение всякий раз, когда есть сложная проверка строк (номера телефонов, электронные письма, ss #, IP-адреса), где есть хорошо известные регулярные выражения. Получите его с regex.org, укажите авторство с комментарием и / или получите разрешение авторов, в зависимости от того, что подходит, и покончите с этим.

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

Но если вы пишете свой собственный, а не чужой,

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

Стоит ли Regex хлопот для вас? Не знаю. Зависит от того, насколько серьезно вы относитесь к тому, что делаете.

Я только что столкнулся с этой проблемой. Я построил регулярное выражение для извлечения групп данных из длинной строки чисел и некоторого другого шума. Регулярное выражение было довольно длинным, хотя и кратким, и стало еще больше, когда я попытался добавить его в приложение C #, которое я писал. Всего reg ex состоял из 3 строк кода.

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

Что лучше? Мое эго говорит регулярные выражения. Любой новый сотрудник скажет «раздевание».

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

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

Между прочим, приложения обычно являются CRM.

Так что хлопоты для меня ограничиваются поиском в Google регулярного выражения на случай, если мне понадобится. ;)

Как ни странно, весь код необходимо оптимизировать, где это возможно!

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

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

Прочтите раздел «Использование тестов» на JavaWorld.

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

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

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

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

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

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

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

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

Также представьте себе, если вы проверяли номера телефонов и решили использовать код вместо reg ex. Итак, это, скажем, 20 строк. Со временем ваша компания решает расшириться в другие регионы, где проверка телефона уже не совсем верна. Поэтому вам нужно настроить его в соответствии с другими требованиями. Возможно, что код будет труднее поддерживать, потому что вам придется корректировать более 20 строк кода, а не просто удалять старый reg ex и заменять его новым.

Однако я думаю, что код можно использовать в некоторых случаях вместе с регулярным выражением. Например, предположим, что вы хотите проверить номера телефонов в США, в каждом случае они имеют 10-значные номера, но существует буквально масса способов их записать. Например (xxx) xxx-xxxx или xxx-xxx-xxxx, или xxx xxx xxxx и т. Д. И т. Д. И т. Д. Так что, если вы напишете reg ex, вам придется учитывать каждый из случаев. Однако, если вы просто удалите все нечисловые и пробелы с помощью замены регулярного выражения, а затем выполните второй проход и проверьте, есть ли в нем 10 цифр, вам будет проще, чем учитывать все возможные способы записи номера телефона.

Я думаю, что в некоторых случаях код можно использовать вместе с регулярным выражением. Например, предположим, что вы хотите проверить номера телефонов в США, в каждом случае они имеют 10-значные номера, но существует буквально масса способов их записать. Например (xxx) xxx-xxxx или xxx-xxx-xxxx, или xxx xxx xxxx и т. Д. И т. Д. И т. Д. Так что, если вы напишете reg ex, вам придется учитывать каждый из случаев. Однако, если вы просто удалите все нечисловые и пробелы с помощью замены регулярного выражения, а затем выполните второй проход и проверьте, есть ли в нем 10 цифр, вам будет проще, чем учитывать все возможные способы записи номера телефона.

Я думаю, что в некоторых случаях код можно использовать вместе с регулярным выражением. Например, предположим, что вы хотите проверить номера телефонов в США, в каждом случае они имеют 10-значные номера, но существует буквально масса способов их записать. Например (xxx) xxx-xxxx или xxx-xxx-xxxx, или xxx xxx xxxx и т. Д. И т. Д. И т. Д. Так что, если вы напишете reg ex, вам придется учитывать каждый из случаев. Однако, если вы просто удалите все нечисловые и пробелы с помощью замены регулярного выражения, а затем выполните второй проход и проверьте, есть ли в нем 10 цифр, вам будет проще, чем учитывать все возможные способы записи номера телефона.

или xxx xxx xxxx и т. д. и т. д. и т. д. Итак, если вы напишете reg ex, вам придется учитывать каждый из случаев. Однако, если вы просто удалите все нечисловые и пробелы с помощью замены регулярного выражения, а затем выполните второй проход и проверьте, есть ли в нем 10 цифр, вам будет проще, чем учитывать все возможные способы записи номера телефона.

или xxx xxx xxxx и т. д. и т. д. и т. д. Итак, если вы напишете reg ex, вам придется учитывать каждый из случаев. Однако, если вы просто удалите все нечисловые и пробелы с помощью замены регулярного выражения, а затем выполните второй проход и проверьте, есть ли в нем 10 цифр, вам будет проще, чем учитывать все возможные способы записи номера телефона.

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

В регулярных выражениях .NET вы можете иметь комментарии и разбивать их на несколько строк, использовать отступы и т. Д. (Я не знаю о других диалектах ...)

Используйте параметр "игнорировать пробелы в шаблоне" и либо # для комментирования остальной части строки, либо "(#comments)" в вашем шаблоне ...

Так что, если вы хотите, вы можете сделать их вроде как читабельными /maintainable...

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

With great power comes great responsibility!

Regular expressions are great, but there can be a tendancy to over-use them! There are not suitable in all cases!

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

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

Использование регулярного выражения имеет некоторые преимущества:

• Время . Ты не Чтобы делать именно то, что встроено, нужно писать собственный код.
• Ремонтопригодность . Вы должны поддерживать только пару строк вместо 30 или 300
• Performance . Код оптимизирован
• Надежность . Если ваше регулярное выражение верное, оно должно работать правильно.
• Гибкость . Regex дает вам много возможностей, которые очень полезны при правильном использовании

Я думаю о поддержании кода, а не о времени выполнения по прямой.

Размер кода - единственный наиболее важный фактор в снижении ремонтопригодности.

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

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

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

С уважением

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

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

a = re.compile(r"""\d +  # the integral part
               \.    # the decimal point
               \d *  # some fractional digits""", re.X)

Другая возможность - построить регулярное выражение из строк, по строке и прокомментируйте каждую строку, например:

a = re.compile("\d+"  # the integral part
               "\."    # the decimal point
               "\d *"  # fraction  digits
               )

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

Professional developers should be familiar with basic syntax

At the very least. In all the years long I've been a professional developer I haven't come across a developer that wouldn't know what Regular Expressions are. It's true, not everybody likes using them or is very good at knowing its syntax, but that doesn't mean one shouldn't use them. Developers should learn the syntax and regular expressions should be used.

It's like: "Ok. We have Lambda expressions, but who cares, I can still do it the old fashioned way."

Not learning key aspects of professional development is pure laziness and shouldn't be tolerated for too long.

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

Я использовал tsqlunit , и только что заметил это от Microsoft, которое похоже на модульное тестирование базы данных. Есть также серия статей о Simple-Talk Алекса Кузнецова , которые вы можете прочитать, если вы еще не сделали этого.

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

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

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