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

Такой вопрос:

    //NOTTODO: IT: The name is the best ever. Don't change it.
    public static string Args([NotNull] this string format, params object[] args) => string.Format(format, args);

Чот я не уверен в best ever.

UPD: Я знатно протупил с вариантом .Format(), AndrewVK намекнул ниже Но Args мне всё равно не нравится

Аргументы против в произвольном порядке:
0. Guidelines. Имя метода не совпадает с производимым действием.

1. WTF test fail.
Возьми произвольного девелопера и спроси: "эй, у нас будет метод-расширение для форматирования строк, как он должен выглядеть?"
Сколько напишут

var sayHelloFormat = @"Hello, {0}"!
...
return sayHelloFormat.Args(wellKnownNames[0]); // WTF???

вместо

var sayHelloFormat = @"Hello, {0}"!
...
return sayHelloFormat.Format(wellKnownNames[0]);

?


2. Совместимость с другими решениями. В куче проектов используется SmartFormat с extensions вида

var x = "You have {0} new {0:message|messages}".SmartFromat(emails.Count);
var y = "You have new message(s): {0}".Args(emails.Count); // WTF???

3. Too noisy. Подобные узкоприменимые расширения должны быть opt-in. Иначе после подключения юзинга ради полезной фичи (например, NotNullNorEmpty()) intellisence засоряется куда менее полезными Точнее, абсолютно бесполезными с учётом пары SmartFromat + c# string interpolation. Только чур не спорить "это ж один метод, фигня!".
У меня из-за таких дачобудет в одном из доставшихся в подарок проектов только на object 12 extension-ов вылазят. Нафиг-нафиг.


Ну, т.е.
1. Переименовать в .Format() .StringFormat() или что-то типа того.
2. Спрятать в отдельный namespace.
Это всё не ради срача, а чтоб сделать код лучше. Если решение принципиально будет "всё равно останется как есть" — можно не спорить, просто так и скажи