Как стать автором
Обновить

Комментарии 21

ОБМ. Да это просто праздник какой то.
Большое спасибо за релиз, Go to everything замечательный!

В тему автокомплита — мне очень нравятся Live templates и особенно их регионозависимость, но я почему-то не могу переносить автокомплит в решарпере и использую студийный. Можно ли как-то полноценно использовать темплейты со стандартным комплитом? Вызывать вставку через хоткей — не самое приятное занятие.
Увы, такой возможности нет. Ctrl+E,L (в студийной раскладке) или Ctrl+J (IntelliJ-раскладка) — единственный вариант вставки шаблонов в обход IntelliSense.

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

Условия апгрейда академических лицензий аналогичны персональным.

Дополнительно отмечу, что всем клиентам персональной и академической категорий, кто купил или обновился до версии 7 в мае этого года, рекомендуется написать в отдел продаж и попросить скидку на обновление — как правило, они её предоставляют.
А как же ваше обещание про добавление поддержки С++ в 8-ой версии?
Предже всего, хочется в очередной раз подчеркнуть что поддержка С++ не будет включена в ReSharper 8 потому что она еще «сыровата» для полноценного продакшн-релиза.

(Поддержка C++ в ReSharper)

Вы это обещание имеете в виду, или какое другое?
Да, видимо подзабыл малость это заявление.
На правах примечания: скриншоты в разделе про архитектурные инструменты снимались на предрелизной версии ReSharper 8.0. С тех пор оформление графов зависимостей существенно изменилось. Чтобы посмотреть, как они выглядят сейчас, ознакомьтесь с этим видео.
Пофиксили ли property with backing field, которые при рефакторинге создавались не рядом, а вверху класса?
Вы имеете в виду context action «To property with backing field»? В каком языке?
C#
В 6 версии емнип когда конвертилась auto property to property with backing field, то приватное поле ставилось рядом с пропертей. В 7 появилось упорядочивание, и приватное поле начало уезжать в начало класса, что чертовски неудобно.
1. Касаемо «пофиксили» — поля стали создаваться рядом с другими полями не из-за какого-либо бага, а из-за пачки реквестов пользователей, которым надоело самим таскать поля после контекстных действий. Исследовав ситуацию с предпочтениями расположения полей в layout'е классов в различных доступных солюшенах пришли к выводу, что расположение поля рядом со свойством — куда менее распространенный кейс, чем группировка полей вместе.

2. Как только возникают подобные ситуации (http://xkcd.com/1172/) — помогает завести нам реквест или проголосовать за существующий. Где-то я такой реквест видел, наверное прийдётся сделать настроечку на 8.1, чтобы были счастливы все. Простите, если это доставило так много неудобств.

3. От меня лично: от схемы layout'а классов «поля рядом с их свойствами» на самом деле лучше отказаться, так как никто не может толком ответить — где располагать поля, не привязанные к свойствам? Большинство располагают в начале класса, но почему тогда внезапно имеет смысл размещать другие поля рядом со свойствами — не понятно. Совсем не понятно, где размещать поле, если оно может рассматриваться как «backing field» сразу нескольких свойств. Само понятие — «backing field» — очень сложно даже лишь пытаться формализовать (public List XS { return xs ?? (xs = new List()); } — тут «xs», это «backing field»? А если в акцессорах встречаются несколько полей? И ещё очень много чего магического может быть написано в акцессорах). В решарпере минимум эвристик на эту тему. Подобный class layout невозможно выразить в нашем code cleanup для автоматического реордеринга членов классов, не смотря на сложность языка описания class layout'а. Ну и из личного опыта — когда весь стейт типа в одном месте, это удобнее, чем внезапно обнаруживать поля где-нибудь между методов в совсем неожиданных местах.
Для меня это самое backing field — это то что было auto property (public T Prop { get; set; }), а захотелось инициализацию, чтобы не мучиться с null. Всякое страшное использование нескольких пропертей на одном поле или проперти со страшной логикой — от лукавого и не про то.

Опять же имхо: когда близкие по семантике члены класса собраны вместе — это удобно, потому что когда правишь какой-то функционал, обращаешься именно к семантическому куску (ну например реализацию интерфейса удобно даже в #region заворачивать). Я когда-то пытался использовать «структурный» layout с группировкой по формальным признакам языка и понял, что это мне мешает, вместо того чтобы помогать. Бегание по всему файлу отнимает время, особенно если файл большой.
Зачем вам бегать по файлу, если вы пользователь решарпера?
Интереса ради, Go to File Member, Go to Usages of Symbol, Alt+вверх/вниз — вы всем этим пользуетесь?
Нет, этим не пользуюсь.
Вместо этого у меня Go to Declaration (aka Ctrl+Click) и Find Usages. Наверное, это потому что я не помню, как у меня называются члены класса.
А никуда не ходить мне удобней, чем куда-то ходить, пусть даже это и просто.
Прошу прощения что отвечаю так поздно — только сейчас в очередной раз загуглив решение проблемы увидел комментарий. Дело в том что XAML разработчикам при создании ViewModel очень много приходится создавать property with backing field только для того что бы вызывать OnPropertyChanged для этого поля или дополнительно для нескольких полей. И таких полей приходится делать очень много. И при этом рефакторинг значительно усложняется если решили что это поле должно быть в другой VM. Вместо того что бы «вырезать»-«вставить» получаем «вырезать» «вставить» вернуться, найти это поле где оно было «вырезать», «вставить». Если решили удалить это проперти совсем — можно запросто забыть удалить поле наверху и т.д. и т.п. Да при построении логики это может быть и удобно когда поле генерируется на верху, но при активной работе с VM (а эта чуть ли не львиная доля работы для тех кто работает с XAML) это страшно неудобно и раздражает. То же самое касается Dependency Property. А в целом решарпером очень доволен — один из тех продуктов за который не жалко потраченных денег, но вот это «фича», которая по мнению JetBrains сделала нашу жизнь гораздо проще, субъективно снижает ценность продукта.
Всё это происходит отдельном потоке, поэтому пока ReSharper делает свою работу, вы можете продолжать писать код.

Когда же мы будем пить кофе, а Решарпер будет писать код, «в отдельном потоке»? :) Спасибо, замечательную тулзу!
У меня в финальной версии все так же есть глюк, что в некоторых классах в саджесте нет полей и методов текущего класса. Локализовать к сожалению не могу :(
Если таки сможете, напишите, пожалуйста, в трекер.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий