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

S>Коротко и быстро: найти косяк в таком рефакторинге

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

Об этом речь?

S>Только с пруфами цыферками, пожалуйста.

Если только позже

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

VD>>Макра мало чем от функции отличается. Отладил и используешь неограниченное время. Тем более такая простая.
S>Такая простая — да, чуть посложнее — надо очень внимательным быть.

Примерно как с любым другим кодом.

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

Вот возьмем к примеру тот же макрос сериализации сообщений.

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

Без макросов эта задача решается менее эффективно и приводит к существенно большему объему кода.

S>Потому что если в часто используемой функции баг — достаточно выпустить минорный фикс.
S>Если такой же баг в кодогенерации — надо перепоставлять весь код.

Это какой-то фантастический случай. Если макрос писался по делу (а не кто-то набыдлокодил потому что мог), вместо использования макроса ты будешь вынужден разнести кучу не очень красивого кода по всему проекту (возможно не по одному).

Берем твоей текущий пример. Вместо макры ты будешь вынужден использовать менее эффективный и менее элегантный вариант принимающий форматную строку и доп. параметры или загадить код ВСЕГО ПРОЕКТА if-ами.

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

S>Для проекта в несколько сотен МБ бинарников это упс.

Вот именно!

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

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

R>>Об этом речь?
S>Изверг, всю интригу убил

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

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

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

S>Так вот, если весь код поставляется одним куском — всё зашибенно.
S>Если регулярно выходят хот-патчи для отдельных библиотек или надо починить код, который сгенерился в том числе в third-party коде, то ой.

S>Не, понятно, что сдуру всё сломать можно, но узнать это сложным способом было очень забавно
Это из серии

- Говно ваш Поваротти!
— Ахренеть, ты его слушал?!?
— Да, нет, Петька напел!

Макра мало чем от функции отличается. Отладил и используешь неограниченное время. Тем более такая простая.

Продолжаем продолжать

Автор: Sinix
Дата: 27.03.16

Коротко и быстро: найти косяк в таком рефакторинге

        Assert(x > 0, "Value of x ({0}) should be greater than zero.", x); 
// =>
        Assert(x > 0, $"Value of x ({x}) should be greater than zero.");  // (с) решарпер :))

Только с пруфами цыферками, пожалуйста.

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

VD>Это тот случай кода макры рулят. Можно легко переписать код в if и проблем не будет.
С одной стороны согласен от и до.

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

Так вот, если весь код поставляется одним куском — всё зашибенно.
Если регулярно выходят хот-патчи для отдельных библиотек или надо починить код, который сгенерился в том числе в third-party коде, то ой.

Не, понятно, что сдуру всё сломать можно, но узнать это сложным способом было очень забавно

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

S>Изверг, всю интригу убил

Ой

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

R>Об этом речь?
Изверг, всю интригу убил

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

R>>Об этом речь?
S>Изверг, всю интригу убил

Это скорее проблемы вашего Assert который перегружен лишним функционалом. Строка ему вообще не нужна — достаточно TMessage: IFormattable

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

TK>Это скорее проблемы вашего Assert который перегружен лишним функционалом. Строка ему вообще не нужна — достаточно TMessage: IFormattable

Ну, т.е., волевое решение команды рослина
"есть кандидаты FormattableString и string, тип параметра FormattableString, но мы будем использовать string" — эт наши проблемы?
Так-то да, но от этого легче не становится

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

        static void Assert(bool x, string message)
        {
            if (!x)
                throw new InvalidOperationException(message);
        }
        static void Assert(bool x, string messageFormat, params object[] args)
        {
            if (!x)
                throw new InvalidOperationException(string.Format(messageFormat, args));
        }

        static void Assert<TMessage>(bool x, TMessage messageFormat) where TMessage : IFormattable
        {
            if (!x)
                throw new InvalidOperationException(messageFormat.ToString(null, null));
        }

        static void Main(string[] args)
        {
            Assert(true, "hello");
            Assert(true, $"hello #{1 + 1}");
        }

Вдовесок, из-за таргетинга на 4.0, придётся объявлять свой System.FormattableString, причём как public.
На ровном месте получаем тонну

Warning    CS0436    The type 'FormattableString' in 'Program.cs' conflicts with the imported type 'FormattableString' in 'mscorlib, Version=4.0.0.0 ...'

россыпью.

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

VD>Макра мало чем от функции отличается. Отладил и используешь неограниченное время. Тем более такая простая.
Такая простая — да, чуть посложнее — надо очень внимательным быть.

Потому что если в часто используемой функции баг — достаточно выпустить минорный фикс.

Если такой же баг в кодогенерации — надо перепоставлять весь код.
Для проекта в несколько сотен МБ бинарников это упс.

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

R>Если только позже

Ну вот как всегда мне отдуваться

Format+args:           149,2424
Interpolated:          2839,4277
Formattable(explicit): 148,9976

Done.

gist.

Неплохой такой упсик в ~20 раз, да?

Мораль: пишите в спортлото перфтесты.

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

S>Мораль: пишите в спортлото перфтесты.

Предлагаю другую мораль — "не занимайтесь <сами_знаете_чем>"

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


K>Предлагаю другую мораль — "не занимайтесь <сами_знаете_чем>"

Ну тут как... кто-то не мается, а кто-то после чужого "дачотамдумать" авралы чинит
Вылезло после очередного "джуниор поставил решарпер".

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

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

VD>Это тот случай кода макры рулят. Можно легко переписать код в if и проблем не будет.

Это тот случай, когда можно вообще ничего не делать.

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

A>Это тот случай, когда можно вообще ничего не делать.

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

Такие вот темы они ведь не на пустом месте появляются. Обычно бывает так... Был код работавший с приемлемой скоростью. Вышла новая ветсия РеШарпера, которая предложила махнуть не глядя string.Format на интерполируемые строки. Программист ничего не подозревая махает, а потом день убивает на поиски внезапно возникших тормозов.