Потому что 283 итерации - это константа. Которая зачастую перебьется тем фактом, что вы вместо простой и кэш-френдли структуры массива использовуете развесистое дерево.

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

Окей, вот решение на C# со сппитами: https://gist.github.com/vlova/27c1eecdc17c139e33db6e2d78dcea2d

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

2. В отличие от вашего решения — есть валидация ренджей. И т.д., и т.п.

3. Нечитабельно? Да вроде как читабельно и даже симпатично

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

5. Да, создает объекты в куче. Вообще по барабану, у C# нормальный сборщик мусора, объекты попадут в Gen0 и соберутся даже раньше, чем метод закончит работу

6. Медленнее? Да наверняка. Но надо бенчить насколько это медленнее. И скорее всего это не критично, потому что этот метод не будет вызываться часто.

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

Ваш код хорош, он читаем и в не которых пределах расширяем (пока грамматика не станет очень сложной, но это вряд-ли)

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

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

Это значит, что некоторые рекомендации крайне плохи.

Но если вам хочется им следовать, то можно просто вынести хотя-бы в переменные.

Ну, джуны никому не нужны, поэтому их можно мучать как угодно - да.

Но для синьоров тестовые задания тоже часто бывают.

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

С осложнениями:

1. У каждой "цифры" разный набор доступных значений. Причем в случае цифры "день" - оно еще зависит и от месяца/года

2. Особые проблемы несет то, что все эти компоненты "именованные". Из-за этого красивый код написать трудно.

3. Число 32 как последний день месяца

4. Есть day of week, который определяется из year/month/day. Но можно просто последовательно инкрементить дату, пока не найдём подходящую под day of week. Хотя авторы quartz предпочли более оптимизированное решение

Как внутренний класс для целей парсинга - это хорошо.

Проблема в том, что это не очень хорошо подходит для поиска следующих событий. Ведь на входе может быть строка вида "10-20/3,18-200/2" - т.е несколько SchedulePart. По нескольким SchedulePart трудно ввести перебор в отсортированном порядке

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

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

А автор (и NCrontab) не пытаются, они просто отдельно отсекают такие даты как неправильные.

Кстати, @novar, сейчас вы можете сравнить предложенное мною решение (только по парсингу пока, увы) со своим. Что по читабельности, что по производительности.

• У NCrontab все же посимпатичнее выглядит, чем у Quartz

• У Quartz код сильно зашкварился из-за того, что они поддерживают day of week (mon, tue, wed). Там примерно ¼-⅓ кода чисто из-за этого написана. А вот автору day of week не надо

• Мне все же не нравится даже решение NCrontab, но полагаю, что это самое лучшее, что можно сделать, если не морочиться, но при этом добиваться эффективности.

Я думаю, что требовалось.

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

Это весьма ужасно и компания сильно много хочет от кандидата.

Если вы преобразуете текст в набор событий, то у вас получится слишком много событий. Грубо говоря, текст может выглядеть как указание "раз в 1мс" и у вас получатся все миллисекунды от 2000 до 2100 — а их очень много.

спасибо, насмешили. Куда уж моему варианту до чего-то такого по понятности

Спасибо за предоставленную ужасную регулярку. Специально для вас я решил показать, как выглядит нормальное использование регулярок. См. полноценное решение парсинга здесь: https://gist.github.com/vlova/544d693cc4083caafa477383b2e1c216

См. ParseSchedule.pattern и ParseCronSubRange.cronPartPattern.

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

Вообще, сопроводительная документация к коду — это очень важная вещь в рабочих условиях.

Но еще более важно это становится, когда делаются зарисовки кода и трансфер кода к незнакомым лицам. Потому что не телепаты и нет возможности прояснить лично. Как минимум нужно high-level обзор писать.

Вообще, сопроводительное письмо к коду — это очень важная вещь.

Но еще более важно это становится, когда делаются зарисовки кода и трансфер кода к незнакомым лицам. Как минимум нужно high-level обзор писать.

Нет, cron expression из quartz не поддерживают такого "или". Только "и". Например, "каждый четверг в 12:00".

"Или" там поддерживается только на уровне одной штуки. Например, "каждый четверг или среду". Или сложнее: "12:00 каждого четверга/среды".

В целом за исключением мелких деталей задача решается та же самая.

Маленькие уточнения:

• ldloca.s не аллоцирует переменную, ldloca.s загружает адресс переменной в стек (см. https://docs.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.ldloca_s?view=net-5.0)

• да, аллоцирование происходит в обоих случаях, но в первом случае оно происходит раз на жизнь метода (благодаря секции locals). Во втором случае оно происходит на каждой итерации while