История одного фееричного провала тестового задания на C#

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

- фраза применимая к абсолютно любому коду.

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

История одного фееричного провала тестового задания на C#

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

Тот же вопрос по бенчмаркам к вам.

Ваш вариант это вещь в себе. Спросить если что можно только у вас. Если вы уволились, то вообще спросить некого. 

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

 {"..  ::.", null}, // yyyy.MM.dd w HH:mm:ss.fff

Мне как-то сложно поверить, что нужно быть Шерлоком Холмсом, чтобы сопоставить ключ с комментарием.

История одного фееричного провала тестового задания на C#

Что-то вас из крайности в крайность кидает: то

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

- попытка продумать все до мелочей, то

Ну если вот «на коленке»

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

При этом регексы и форматы для штатных парсеров для среднего программиста будут понятнее чем ваш проприетарный формат.

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

@"^(?("")(""[^""]+?""@)|((0-9a-z*)(?<=[0-9a-z])@))"

История одного фееричного провала тестового задания на C#

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

История одного фееричного провала тестового задания на C#

Форматы, да, могут дополняться, но мы ведь говорим про конкретное задание с определенными входными данными. Указано, что "Каждую часть даты/времени можно задавать в виде списков и диапазонов", т.е. "*.9.*/2 1-5 10:00:00.000" этим «yyyy.MM.dd HH:mm:ss» не распарсить.

История одного фееричного провала тестового задания на C#

«yy.MM.dd HH:mm:ss» то же самое, что и «yyyy.MM.dd HH:mm:ss» (который уже есть), просто в парсере надо будет учесть, что год может состоять и из 2 символов. По поводу "чем вас не устраивает" не совсем понял... указанного вами формата нет в задании.

История одного фееричного провала тестового задания на C#

Я бы использовал схему (совокупность точек, пробелов, двоеточий) для определения формата строки:

private static readonly IReadOnlyDictionary<string, IParser> SchemaToParser = new Dictionary<string, IParser>
{
    {"..  ::.", null}, // yyyy.MM.dd w HH:mm:ss.fff
    {".. ::.",  null}, // yyyy.MM.dd HH:mm:ss.fff
    {"::.",     null}, // HH:mm:ss.fff
    {"..  ::",  null}, // yyyy.MM.dd w HH:mm:ss
    {".. ::",   null}, //yyyy.MM.dd HH:mm:ss
    {"::",      null}  //HH:mm:ss
};

private static string GetSchema(string scheduleString)
{
    var separators = scheduleString.Aggregate(new List<char>(), (list, c) =>
    {
        if (c == '.' || c == ' ' || c == ':')
            list.Add(c);
        return list;
    });

    return new string(separators.ToArray());
}


public void Schedule(string scheduleString)
{
    var schema = GetSchema(scheduleString);

    if (!SchemaToParser.TryGetValue(schema, out var parser))
        throw new ArgumentException(nameof(scheduleString));

    //...
}

А дальше написал бы парсер под каждый конкретный случай.