Бля Иисус, пизданул просто как господь, им нужно найти две одинаковые буквы, и вместо того что бы написать простенькую функцию, эти ленивые пидорасы хуярят эту адскую уродливую не производительную макаронину, которую блять потом даже бухим не разберешь
А иногда наоборот, приходит индус-умник, который думает, что умнее всех, оптимизирует регулярку и несколько правил валидации улетают в трубу, хотя на первый взгляд вроде ничего подозрительного.
Я видел вещи, которые не должны видеть люди. Регулярка, собираемая по ходу генерации файла, которую парсят.. Другой регуляркой поменьше! И все это для вполне себе не сложных задач. В такие моменты хотелось бы, чтобы регулярок небыло вообще, тогда там бы просто было двести ифов и парсов строки, с этим намного проще работать
За этот конкретный случай ничего не могу сказать - не видел, но в целом регулярка гораздо лучше в поддержке, чем двести ифов и парсов строки (и несравненно быстрее).
Вычислитель регулярок писали не говнокодеры-формошлепы, а люди знакомые с алгоритмами, оптимизацией и тд. И он (код) гораздо сложнее самой регулярки потому что универсален
Если попытатся втащить что то подобное в обычное прикладное приложенние, тебя проклянут еще на стадии код-ревью
Работать может примерно так же как и регулярка, но этот код будет заточен только под конкретный кейс. А теперь представь что таких кейсов в приложении сотня и с каждым надо разобраться. а регулярка она универсальна, даже новый девелопер может понять что там происходит без дебага десятка вложенных циклов
> и подожди результат несколько дней
> Работать может примерно так же как и регулярка
Так несколько дней или "так же"?
Феерическая апелляция к низкому быстродействию (в контексте абстрактной мысли из сферического вакуума, вообще-то) волшебно эволюционировала в рассуждения о читабельности, сопровождаемости, универсальности, etc.
Средний девелопер не напишет хороший код имитации регулярки. Sad but true...
А не средний потратит на него гораздо больше времени чем на написание самой регулярки. Собственно начиная с библиотек языка Си все идет по пути универсализации стандартизации и избавления от рутинных операций и только мамкины хакеры до сих пор пишут свою операционную систему
Нет тут все зависиь от тз, если тебе нужно выполнить операцию за 0.01с то ты должен ее выполнить за 0.01с и если регулярки или уеиверсальные библиотечные методы не могут тебе обеспечить этого, то хочешь не хочешь будешь писать оптимизированный под свою задачу фрагмент кода
Прости, но это вызывает у меня добрую улыбку. Я уже стар и повидал всякого дерьма, но такая детская непосредственность всегда умиляет.
Это как команде землекопов сказать:
Заказчик: Надо выкопать котлован за 1 день!
Бригадир: так производительности экскаватора недостаточно! Будем копать вручную!
Чет у тебя хреново получаеться в аналогии, это скорее как нужно выкопать яму 10 на 10 милиметров а у тебя толькл эксковатор и ты говооишь что можешь выкопать яму только метр на метр
Нет это скорее инструмент, который позволяет выкопать яму любого размера за разумное время, которое не зависит линейно от объема ямы.
В твоем же случае ты предлагаешь под каждую яму конструировать инструмент и только потом копать. Причем качество твоего инструмента под вопросом.
Ну а ТЗ в стиле "нужно за 0.1 мс" я даже не хочу комментировать.
Оф кос преждевремення оптимизация хуже преждевременной еакуляции, но потом когда ты померяешь критические секции кода и окажеться что они работают медленно ты все равно будешь писать свой заточенный под свою задачу фрагмент кода, это же не значит, что ты сразу с нуля начинаешь свои велосипеды городить
Твое псто меня не менее умиляет. Я, конечно, понимаю о чем ты, и по бОльшей части согласен, конечно, но как человек уже очень давно разрабатывающий под микроконтроллеры и прочее железо - повидал всякого не меньше. И да, если тебе нужно уложиться в заданное время то ты должен в него уложиться, и похуй, хоть экскаватором, хоть стремительным домкратом. А не рассказывать про универсальность готовых решений, их недюжинную оптимизацию и читабельность кода.
Из недавних примеров. Парсинг некоего околотекстового протокола в условиях очень ограниченного времени и памяти, когда полный кадр хранить тупо негде и, следовательно, парсить нужно потоково. Можно было б и классными регекспами. Только хер бы они со всеми своими гениальными оптимизациями и универсальностью вложились в условия, в первую очередь по памяти. Потому пришлось применять всякий изврат, вроде представления групп из четырех символов как 32-битного числа и switch/case по ним. В итоге получилось не так уж монстроидально как можно было ожидать, и работало прекрасно. Более того: код получился вполне читабельный. И нет, идея не моя - я ее подсмотрел в одном забавном парcере NMEA.
Второй пример: пришлось запилить табличный логарифм для очень быстрого прогнозирования времени переходного процесса на емкости в изменяющихся условиях.
В современном мире все еще есть место для 0x5f3759df, не взирая на обилие фреймворков и "программирования мышкой".
Не хотел влезать в вашу дискуссию, но почему бы не использовать устройство с нормальным объёмом памяти, в который полный кадр влазит? 640 килобайт уже давно ни для кого не достаточно, а память за десятилетия сильно подешевела, даже на микроконтроллерах найдётся куда запихнуть.
Я на прошлой работе поддерживал программу, написанную на плюсах под дос, устройство - MicroPC (не микроконтроллер, конечно - под микроконтроллер программу поддерживал другой человек). Так это говно поддерживали, пока основную плату с производства не сняли, и только тогда контора зачесалась и начали работать над модернизацией всего оборудования. И оказалось, что к 2016-му новых контроллеров выпущено навалом, бери да покупай.
Ну ты же понимаешь насколько твой пример узко специализирован?
Ну и вообще я не за то что не надо думать и писать оптимальные программы. Все началось с того что "регулярки говно потому что я их не понимаю" (это не ты сказал если что)
Так вот не гавно. А вполне себе хорошая и полезная фича, проверенная временем и вполне себе востребованная
Да только если что регулярка работает в 10 а то и в 100 раз медленее функции заточеной под определенный кейс, хз вообще с чего вы взяли что она работает так же
Ну можешь сам дома проверить если не впадлу будет, регулярка очень жирная универсальная штука и если есть возможность не использовать ее, лучше не использовать
Я видел такое, что вам, людям, и не снилось... Регулярка, собираемая по ходу генерации файла, которую парсят.. Другой регуляркой поменьше; Регулярки, пронизывающие мрак кода Html-парсеров... Все эти мгновения затеряются во времени, как слёзы в дожде. Время... умирать
Ну если у тебя десятки вложенных if then else, то любой анализатор будет ругаться на цикломатическую сложность и, возможно, это повод что-то переделать :)
Ну хз, люблю регулярки, хотя нихуя в них не умею. Благо есть такие замечательные сайты как https://regex101.com/ и его аналоги, где можно в реальном времени набросать регулярку и глянуть как она работает.
capture groups с back references кроме всего прочего тормоза
если можете обойтись без, обойдитесь без, даже если это значит реструктуризацию выражения или даже кода
Регулярки - отличный способ добавить к решаемой проблеме еще одну. Но. Если принять факт, что регулярки - это write-only и модифицировать их нельзя, только переписывать, как-то жить легче становится.
Первый день в программировании
Google
О. regex для проверки email X Ш ^
Поиск в Google Мне повезёт!
10-й год в программировании
Google
Q, regex для проверки email X ■ *•/
Поиск в Google
Мне повезёт!
@ithumor
Если попытатся втащить что то подобное в обычное прикладное приложенние, тебя проклянут еще на стадии код-ревью
> Работать может примерно так же как и регулярка
Так несколько дней или "так же"?
Феерическая апелляция к низкому быстродействию (в контексте абстрактной мысли из сферического вакуума, вообще-то) волшебно эволюционировала в рассуждения о читабельности, сопровождаемости, универсальности, etc.
А не средний потратит на него гораздо больше времени чем на написание самой регулярки. Собственно начиная с библиотек языка Си все идет по пути универсализации стандартизации и избавления от рутинных операций и только мамкины хакеры до сих пор пишут свою операционную систему
Это как команде землекопов сказать:
Заказчик: Надо выкопать котлован за 1 день!
Бригадир: так производительности экскаватора недостаточно! Будем копать вручную!
В твоем же случае ты предлагаешь под каждую яму конструировать инструмент и только потом копать. Причем качество твоего инструмента под вопросом.
Ну а ТЗ в стиле "нужно за 0.1 мс" я даже не хочу комментировать.
Из недавних примеров. Парсинг некоего околотекстового протокола в условиях очень ограниченного времени и памяти, когда полный кадр хранить тупо негде и, следовательно, парсить нужно потоково. Можно было б и классными регекспами. Только хер бы они со всеми своими гениальными оптимизациями и универсальностью вложились в условия, в первую очередь по памяти. Потому пришлось применять всякий изврат, вроде представления групп из четырех символов как 32-битного числа и switch/case по ним. В итоге получилось не так уж монстроидально как можно было ожидать, и работало прекрасно. Более того: код получился вполне читабельный. И нет, идея не моя - я ее подсмотрел в одном забавном парcере NMEA.
Второй пример: пришлось запилить табличный логарифм для очень быстрого прогнозирования времени переходного процесса на емкости в изменяющихся условиях.
В современном мире все еще есть место для 0x5f3759df, не взирая на обилие фреймворков и "программирования мышкой".
Я на прошлой работе поддерживал программу, написанную на плюсах под дос, устройство - MicroPC (не микроконтроллер, конечно - под микроконтроллер программу поддерживал другой человек). Так это говно поддерживали, пока основную плату с производства не сняли, и только тогда контора зачесалась и начали работать над модернизацией всего оборудования. И оказалось, что к 2016-му новых контроллеров выпущено навалом, бери да покупай.
Ну и вообще я не за то что не надо думать и писать оптимальные программы. Все началось с того что "регулярки говно потому что я их не понимаю" (это не ты сказал если что)
Так вот не гавно. А вполне себе хорошая и полезная фича, проверенная временем и вполне себе востребованная
Нет млять, мы будем двоих из Сан-Франциско восславлять за обоссаный UML, но кодить будем блоком слипшихся регулярок!
Или и правда, сразу в ОпКоде
если можете обойтись без, обойдитесь без, даже если это значит реструктуризацию выражения или даже кода
2) Используешь регулярные выражения, чтобы её решить
3) Теперь у тебя две проблемы