Re[5]: Interpolated strings: есть идеи, как подправить произ
От: Пельмешко Россия blog
Дата: 19.04.16 19:59
Оценка: 115 (5) +1 :))
Здравствуйте, Sinix, Вы писали:

S>>А вот мне больше вот что интересно: на основании чего решарпер даёт такие ценные советы?

S>Как мне кажется, основной довод — "нам нужно больше фич".

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

С интерполяцией банальная проблема — как только начинаешь ей пользоваться, то случается разрыв — половина кода в проекте $"вот {такая}", а вторая половина ("немного {0}", другая). И возникает банальное желание привести все к одному виду — к интерполяции строк. Не потому что это модно и молодежно, не потому что нам надо что-то новое показывать в редакторе чтобы выглядеть по-прежнему полезным тулом, а потому что мы реально считаем такую форму записи форматный строк предпочтительной в C# 6.0 проектах. Не смотря на то, что интерполяция не позволяет выразить всех сценариев `string.Format`а, все же вы устраняете проблему нетипизированных форматных вызовов. Вдумайтесь, на самом деле R# трансформацией в интерполяцию наоборот делает себя менее полезным!

Что касается проблемы с assert-методами: мы просто продолбали этот сценарий, который конечно здорово подкашивает веру в единообразие кода форматирования строк Мы определенно подточим инспекцию для всех методов, похожих на Assert и всякие WriteIf (думаю, эвристики по сигнатуре или наличия [AssertionMethod] будет достаточно), чтобы срабатывания там не было совсем. Я хочу заметить, что сейчас инспекция "Pass string interpolation" имеет severity HINT, который имеет самых "мягкий" рекомендативный характер и в редакторе хинты еле видно.

К сожалению, фичи для C# 6.0 дизайнятся и имплементятся в момент времени, когда в мире слишком мало C# 6.0 кода чтобы мы наступили на все грабли и учли все косяки до выката релиза. Поэтому мы вынуждены балансировать между желанием научить пользователям новым языковым идиомам и опасностью навредить пользовательскому codebase'у. Ну а дальше уже время и найденные пользователями грабли приводят систему к равновесию, как иначе?

Что касается советуемых R# трансформаций, приводящих к лишним аллокациям или деградирующим производительность — мы никогда не скрывали, что R# в первую очередь руководствуется краткостью/декларативностью/каноничностью кода, а не "производительностью". Это сделано осознанно, а не потому что мы не знаем что какие-нибудь вызовы переопределенных виртуальных методов на типах-значениях устроняет боксинг или что LINQ-методы плодят аллокации на энумераторы и замыкания. Мы можем долго спорить, должен ли обычный .NET программист экономить на каждой аллокации или он все же он знает на что идет когда пишет на языке программирования все более высокого уровня (и в случае реальных проблем возмет профайлер или статический анализатор аллокаций и почистит аллокации на горячем коде), но не думаю что это будет продуктивно.

Еще один момент который я не могу понять — почему если вас волнует "производительность", но есть желание по-прежнему пользоваться R#, то не выключить просто инспекцию и расшарить всей команде...

S>Вот последний, ниччего не поменялось.


Я понимаю ваше неудобство, но блин, придумали же специально диалоговое окно при первых нажатиях хоткеев, которые есть и в VS и R# — выбираешь который нужен и забываешь о проблемах. Без вашего ведома мы давно уже ничего не перебиваем студийное в плане хоткеев, если вы конечно не применили все R#'ные хоткеи разом

S>>Т.е. с чего он решил, что такое преобразование семантически эквивалентно? У него есть какая-то эвристика про string, params object[] => FormattableString?

S>Ну, как эвристика... JetBrains просто добавляют подсказки на каждую новую фичу шарпа, см на те же "To expression body", или "Loop can be converted into a LINQ".

Семантику конечно обычно пытаемся сохранить, но не так "сильно" как компиляторщики (помню обсуждения в розлине a la "а что если структура в .ToString() меняет культуру текущему треду?" по поводу устранения боксинга в конкатенации строк). С интерполяцией в assert-методах переборщили, конечно

Что касается инспекций о новых языковых конструкциях: вы когда-нибудь задумывались сколько программистов узнает о языковых фичах только потому что IDE им рассказало?

Я думаю вас уже не разубедить, что инспекции в решарпере работают из принципа "давай сделаем это... потому что можно!", но лишь добавлю что в инспекциях типа "to expression body" на самом деле даже пишутся эвристики чтобы попытаться понять, будет-ли пользовательский код не менее "читабелен". Например, тела-выражения не советуются когда тело содержит лямбда-выражения (чтобы не получались всякие T P => x => y) или присваивания (мы же не любим когда присваивают внутри выражений, а не отдельным statement'ом, ага?). Оценить глубину выражений и их вид после форматирования сложно, но размышляем и над этим...

S>>Может быть, можно подтюнить решарпер?

S>Угу, есть мысля попросить добавить в JetBrains.Annotations атрибут [ConditionalFormatMethod] и не предлагать interpolated string для таких методов.
S>Осталось найти, где об этом спросить, чтоб дошло до разработчиков, а не отфильтровалось саппортом

Мы вас слышим и обязательно починим этот кейс, спасибо большое что вынесли на обсуждение!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.