Здравствуйте, mgu, Вы писали:

mgu>А скобки и есть математические операции.

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

Здравствуйте, scf, Вы писали:

scf>На хабре выложили интересный разбор решения и предложили "как надо" https://habr.com/ru/post/572052/

А давайте ещё что-нибудь переусложним в тестовом задании на день.

Здравствуйте, scf, Вы писали:

scf>На хабре выложили интересный разбор решения и предложили "как надо" https://habr.com/ru/post/572052/

Мне одному кажется, что "как надо" не лучше, чем "как получилось" по большому счёту?

Здравствуйте, vaa, Вы писали:

vaa>1. быть может отказали почуяв крутого кулцхакера(конкурента).
vaa>слышал в крупных компаниях есть такое ограничение — слишком умных не брать, чтобы не взломали систему.
Вообще то слишком умных, которые хреначат 10 уровней вложенности в методе и которых потом не коробит от этого действительно лучше не брать. Ибо я на код мельком посмотрел — мне сразу стало хреново! И это у автора было до черта времени и он делал не спеша, страшно представить что он будет делать когда сроки горят. Так что я полностью на стороне отказавших, сразу по коду виден уровень, что человек был единственным программистом, которого по рукам ни черта не били, при этом даже всяких Макконелов он никогда не читал.

Здравствуйте, elmal, Вы писали:

E>И это у автора было до черта времени

Выполнив задание примерно за сутки

Это много? тут чуть выше написали появился альтернативный вариант, который "намного" лучше
но спустя 5 дней.

Здравствуйте, vaa, Вы писали:

vaa>Это много? тут чуть выше написали появился альтернативный вариант, который "намного" лучше
vaa>но спустя 5 дней.
Во первых там не все 5 дней на фултайме делали. Уверен что на альтернативный вариант максимум час потратили, ибо неимоверно лень. А во вторых, вот такую лютую жуть, который в коде у автора, нельзя ни в коем случае писать вообще никогда, как бы не горели сроки. Ибо потом если он сотворит багу, то искать он ее будет очень долго. Вот именно сейчас пишу лютую жуть, которая должна быть неимоверно оптимизирована, ибо узкое место, и где до черта всяких краеугольных камней. Так я сначала добиваюсь чтоб проходили тесты, делаю чтоб код был максимально читаемый и я сам там не помер. И только после того, как тесты все пройдут, плюс я прогоню вообще тесты на всех данных — только тогда я буду уже делать финальную оптимизацию, при этом еще и бенчмаркая. Финальная оптимизация — это я заменю обход через рекурсию на тупо цикл, предполагая пока голословно, что это будет быстрее. И потом на финальном этапе мне придется вместо одного общего случая писать для разных случаев специализированные копипасты. Если б я сразу хреначил тем жутким спагетти, которое возможно получится на выходе, я бы от багов в процессе отладки помер бы и вряд ли бы к новому году закончил.

Здравствуйте, rosencrantz, Вы писали:

R>>>1. Для чтения выражений нужно какой-то внятный парсер с внятной грамматикой, или хотя бы регулярные выражения. Чтобы грамматика была не в комментах, а в чём-то более-менее компьютерном.
BFE>>Это чтобы было сложнее тестировать или чтобы медленнее работал код?

R>На сложность тестирования это никак не влияет: тесты как были вход->выход, так и остаются.
Не совсем. При разборе входных данных важно, чтобы отбрасывались строки не подходящие по формату (иначе могут быть падения или другие неприятности). Например, очень многие парсеры json падают при правильно подобранной строке. Если парсер написан по простому — то его можно на 100% кода покрыть тестами: обычно этого достаточно, чтобы не было падений (но не спасёт от бесконечного цикла), а вот протестировать таким образом регулярные выражения не получится.

R>Про тормоза не стоит так вопрос ставить. Тормозит не код, тормозит система в конкретном ворклоаде.
Т.е. вы считаете, что для задачи которая оперирует с миллисекундами скорость не важна?
Или, может, точно известно, что это не мобильное устройство и батарейку экономить не надо?

R>Использовать инструменты более высокого уровня (парсер против indexOf) стоит ради читаемости. Короткую регулярку (или десяток регулярок — по одной на каждый случай грамматики) прочитать и понять легче, чем эту лапшу из ифов и волшебных чисел.
Конечно, это реализация разбора трудна для чтения и такой код недопустим, однако это никак не означает, что следует использовать регулярные выражения.

R>Цитата из оригинальной статьи:
R>

R>Добиваться каких то экстремальных показателей в плане оптимизации нет смысла, потому что это приведёт к снижению такого важного показателя как поддерживаемость кода, а будет ли от этого польза — непонятно, поскольку неизвестны условия эксплуатации.

Автор ошибается. В условиях сказано:

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

R>>>Чтобы можно было красиво ругаться "что qwerty не выглядит как число от 1 до 12".
BFE>>И что с этим потом делать?
R>Падать с эксшепшном "плохое выражение: qwerty не выглядит как число от 1 до 12" вместо "плохое выражение".
Не стоит забывать, что это тестовое задание, а не рабочий код.

R>>>2. Решение никак не порезано на отдельные логические куски — программу невозможно читать по частям, только как монолит. Я бы попытался дизайнить в сторону "композиции триггеров". Парсим -> дерево разбора -> составной триггер.
BFE>>В один день уложитесь?
R>Нет, дня 3. А что?
А то, что это тестовое задание, за которое денег не заплатят.

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, scf, Вы писали:

scf>>На хабре выложили интересный разбор решения и предложили "как надо" https://habr.com/ru/post/572052/

vaa>Мне одному кажется, что "как надо" не лучше, чем "как получилось" по большому счёту?

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

Кроме того автор "как надо" забил на оптимизацию, и у него каждый Schedule будет занимать 100+12+32+7+24+60+60+1000 байт. Хоть бы bitarray\bitvector32 использовал для приличия. Или разворачивал бы этот длинный списко только на время поиска.

Здравствуйте, mgu, Вы писали:

mgu>>>Какой вывих мозга?
BFE>>А вы смогли сходу (за одно прочтение) понять, что и зачем делает автор?
mgu>Нет. А надо сходу?
Да, если код не является экстремальной оптимизацией.

mgu>>> Всё же совершенно очевидно:
mgu>>>

mgu>>>     // 32-й день означает последнее число месяца
mgu>>>

BFE>>Это как раз да — это взято из условий.
mgu>Феерично! Тогда первый день месяца -- -1?
Первый день месяца 0 ( хотя в комментах и написано другое ), следовательно индекс 31 — это 32-ой день.

mgu>А при чём здесь C#? Приоритет операций одинаков в большинстве ЯП.
Всякое бывает.

mgu>Без бессмысленных скобок хотя бы так:
Расставление скобок может регулироваться внутренними документами компании.

Здравствуйте, elmal, Вы писали:

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

какая у Вас опасная работа

Здравствуйте, mgu, Вы писали:

mgu>Так дойдёт до:

mgu>

mgu>a + (b * c)
mgu>

Если читать удобнее, то почему нет?

mgu>Заметил, что кадровые говнокодеры, обычно пишушие в таком стиле:

mgu>

mgu>a= 1;
mgu>b =2;
mgu>c = 3;
mgu>

Вместо богомерзкой IDE код пишут в теплом ламповом vi?

mgu>...за однострочный блок без фигурных скобок горло перегрызут.

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

Здравствуйте, elmal, Вы писали:

E>Во первых там не все 5 дней на фултайме делали.

По кол-ву коммитов не скажешь.

Здравствуйте, B0FEE664, Вы писали:


R>>На сложность тестирования это никак не влияет: тесты как были вход->выход, так и остаются.
BFE>Не совсем. При разборе входных данных важно, чтобы отбрасывались строки не подходящие по формату (иначе могут быть падения или другие неприятности). Например, очень многие парсеры json падают при правильно подобранной строке. Если парсер написан по простому — то его можно на 100% кода покрыть тестами: обычно этого достаточно, чтобы не было падений (но не спасёт от бесконечного цикла), а вот протестировать таким образом регулярные выражения не получится.

Это почему? Что может быть проще чем протестировать конечный автомат?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, rosencrantz, Вы писали:

R>>>>1. Для чтения выражений нужно какой-то внятный парсер с внятной грамматикой, или хотя бы регулярные выражения. Чтобы грамматика была не в комментах, а в чём-то более-менее компьютерном.
BFE>>>Это чтобы было сложнее тестировать или чтобы медленнее работал код?

R>>На сложность тестирования это никак не влияет: тесты как были вход->выход, так и остаются.
BFE>Не совсем. При разборе входных данных важно, чтобы отбрасывались строки не подходящие по формату (иначе могут быть падения или другие неприятности). Например, очень многие парсеры json падают при правильно подобранной строке. Если парсер написан по простому — то его можно на 100% кода покрыть тестами: обычно этого достаточно, чтобы не было падений (но не спасёт от бесконечного цикла), а вот протестировать таким образом регулярные выражения не получится.

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

R>>Про тормоза не стоит так вопрос ставить. Тормозит не код, тормозит система в конкретном ворклоаде.
BFE>Т.е. вы считаете, что для задачи которая оперирует с миллисекундами скорость не важна?
BFE>Или, может, точно известно, что это не мобильное устройство и батарейку экономить не надо?

Глобальное потепление ещё забыли. Ваша мифическая система 99% времени занимается разбором расписаний и 1% времени — вычислениями таймстемпов следующих/предыдущих ивентов? Мы поэтому обсуждаем тормоза регулярок, да?

R>>Использовать инструменты более высокого уровня (парсер против indexOf) стоит ради читаемости. Короткую регулярку (или десяток регулярок — по одной на каждый случай грамматики) прочитать и понять легче, чем эту лапшу из ифов и волшебных чисел.
BFE>Конечно, это реализация разбора трудна для чтения и такой код недопустим, однако это никак не означает, что следует использовать регулярные выражения.

См выше.

R>>Цитата из оригинальной статьи:
R>>

R>>Добиваться каких то экстремальных показателей в плане оптимизации нет смысла, потому что это приведёт к снижению такого важного показателя как поддерживаемость кода, а будет ли от этого польза — непонятно, поскольку неизвестны условия эксплуатации.

BFE>Автор ошибается. В условиях сказано:
BFE>

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

Не использовать много памяти — это сколько? Много значений — это сколько? Я из написанного этого прочитать не могу, поэтому интерпретирую как "используйте здравый смысл". Вы прямо микроконтроллер c 4кб памяти разглядели?

R>>>>Чтобы можно было красиво ругаться "что qwerty не выглядит как число от 1 до 12".
BFE>>>И что с этим потом делать?
R>>Падать с эксшепшном "плохое выражение: qwerty не выглядит как число от 1 до 12" вместо "плохое выражение".
BFE>Не стоит забывать, что это тестовое задание, а не рабочий код.

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

R>>>>2. Решение никак не порезано на отдельные логические куски — программу невозможно читать по частям, только как монолит. Я бы попытался дизайнить в сторону "композиции триггеров". Парсим -> дерево разбора -> составной триггер.
BFE>>>В один день уложитесь?
R>>Нет, дня 3. А что?
BFE>А то, что это тестовое задание, за которое денег не заплатят.

Если у человека есть стандарты качества, и он видит, что при таких стандартах задача займёт больше, чем кажется допустимым, всегда можно отказаться. Можно не отказаться, можно сделать какашку, что мы и наблюдаем. Управление проектами в СД в жопе отчасти именно из-за таких вот ребят: я и хреновую постановку задачи приму, и ещё наобещаю за 1 день сделать, а потом ту дрянь, которая получилась, я буду отмазывать именно этим 1 днём, плохой постановкой задачи, стрессом.

Это ведь каким токсичным засранцем надо быть, чтобы требовать возможности проговорить требования и послать всех подальше, если отказываются обсуждать, да? Прикинуть сколько займёт нормальное решение задачи — за которое не стыдно, которое можно читать и расширять, удивиться, что выходит неделя и снова — либо предложить нанимающей компании оплатить это по адекватному рейту, или послать нафиг компанию, если отказываются? Это ведь совсем отморозком нужно быть, в цивилизованном обществе 21 века у нас так не принято, да?

Но автор статьи не такой — товарищ согласился забесплатно без нормальной постановки задачи что-то изобразить за 1 день.

Здравствуйте, vaa, Вы писали:

vaa>Мне одному кажется, что "как надо" не лучше, чем "как получилось" по большому счёту?
Мне вот не кажется. Идея с парсер-комбинаторами — огонь (признаюсь, первый раз про это слышу). Очевидно, по скорости оно отстаёт от ручного разбора, но читабельность и гибкость решает.

Здравствуйте, Doom100500, Вы писали:

D>Здравствуйте, mgu, Вы писали:

mgu>>А можно и так:
mgu>>

mgu>>if (_days[isLastDayInMonth ? 31 : t1.Day - 1] > 0 && _weekDays[(int)t1.DayOfWeek] > 0)
mgu>>

D>Вот это вообще зашквар

В конце предложения подразумевалась точка или двоеточие?

mgu>>>>

mgu>>>>    if (((_days[t1.Day - 1] > 0) || (isLastDayInMonth && (_days[31] > 0))) && (_weekDays[(int)t1.DayOfWeek] > 0))
mgu>>>>

D>Как, в принципе и в оригинале. (Извините погoрячился)

Пропущены 2 запятые. Читаемость!

Здравствуйте, Doom100500, Вы писали:

D>Здравствуйте, mgu, Вы писали:

mgu>>А скобки и есть математические операции.

D>А разве речь не шла о приоритете логических операций?
D>Продолжаю сомневаться, что это изучают во втором классе школы.

Речь щла о базовом классе "математические операции".

Здравствуйте, scf, Вы писали:

scf>На хабре выложили интересный разбор решения и предложили "как надо" https://habr.com/ru/post/572052/

Я наверно пропустил, там конкурс на лучшего говнокодера?

  while (true)
  {
    ...

    if (t1.Month != month)
    {
      continue;
    }
  }

Один гордится тем, что не может написать if, а этот не осилил do while.

Подглядев у Quartz как они ищут дни недели пишем аналогично, сначала подбираем год:

public DateTime NearestEvent(DateTime t1)
{
  while (true)
  {
    while (!_innerSchedule.Years.IsPointAllowed(t1.Year))
    {
      t1 = new DateTime(t1.Year, 1, 1).AddYears(1);
    }
    return t1;
  }
}

Говнокодерство заразно!

Здравствуйте, B0FEE664, Вы писали:

BFE>>>А вы смогли сходу (за одно прочтение) понять, что и зачем делает автор?
mgu>>Нет. А надо сходу?
BFE>Да, если код не является экстремальной оптимизацией.

Я даже техзадания не могу прочитать сходу.

mgu>>>> Всё же совершенно очевидно:
mgu>>>>

mgu>>>>     // 32-й день означает последнее число месяца
mgu>>>>

BFE>>>Это как раз да — это взято из условий.
mgu>>Феерично! Тогда первый день месяца -- -1?
BFE>Первый день месяца 0 ( хотя в комментах и написано другое ), следовательно индекс 31 — это 32-ой день.

Я бы для проверки последнего дня месяца (при отсутствии встроенного метода), просто прибавлял бы к дате 1 день и проверял бы на первое число.

mgu>>Без бессмысленных скобок хотя бы так:
BFE>Расставление скобок может регулироваться внутренними документами компании.

Может. Но это было тестовое задание.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, mgu, Вы писали:

mgu>>Так дойдёт до:

mgu>>

mgu>>a + (b * c)
mgu>>

SVZ>Если читать удобнее, то почему нет?

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

mgu>>Заметил, что кадровые говнокодеры, обычно пишушие в таком стиле:

mgu>>

mgu>>a= 1;
mgu>>b =2;
mgu>>c = 3;
mgu>>

SVZ>Вместо богомерзкой IDE код пишут в теплом ламповом vi?

Автоформатирование появилось не так давно.

mgu>>...за однострочный блок без фигурных скобок горло перегрызут.

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

Это рассогласование исполняемого файла и исходного кода.

В моих богомерзких IDE всё нормально работает.