Комментарии 21
ОБМ. Да это просто праздник какой то.
+3
Большое спасибо за релиз, Go to everything замечательный!
В тему автокомплита — мне очень нравятся Live templates и особенно их регионозависимость, но я почему-то не могу переносить автокомплит в решарпере и использую студийный. Можно ли как-то полноценно использовать темплейты со стандартным комплитом? Вызывать вставку через хоткей — не самое приятное занятие.
В тему автокомплита — мне очень нравятся Live templates и особенно их регионозависимость, но я почему-то не могу переносить автокомплит в решарпере и использую студийный. Можно ли как-то полноценно использовать темплейты со стандартным комплитом? Вызывать вставку через хоткей — не самое приятное занятие.
+2
Увы, такой возможности нет. Ctrl+E,L (в студийной раскладке) или Ctrl+J (IntelliJ-раскладка) — единственный вариант вставки шаблонов в обход IntelliSense.
А вы попробуйте автокомплит в восьмерке — там многое изменилось, вдруг вам понравится?
А вы попробуйте автокомплит в восьмерке — там многое изменилось, вдруг вам понравится?
+2
А как с апгрейдом недавно купивших решарпер 7? Снова платить или действует годовая подписка на обновления?
0
Гляньте в их блоге чтобы точнее, но кажется они отвечали так — для персонального использования апгрейд бесплатен для те, кто купил после 1 июня, для коммерческих бесплатен, если действует годовая подписка на обновления.
+1
Совершенно верно.
Условия апгрейда академических лицензий аналогичны персональным.
Дополнительно отмечу, что всем клиентам персональной и академической категорий, кто купил или обновился до версии 7 в мае этого года, рекомендуется написать в отдел продаж и попросить скидку на обновление — как правило, они её предоставляют.
Условия апгрейда академических лицензий аналогичны персональным.
Дополнительно отмечу, что всем клиентам персональной и академической категорий, кто купил или обновился до версии 7 в мае этого года, рекомендуется написать в отдел продаж и попросить скидку на обновление — как правило, они её предоставляют.
+2
А как же ваше обещание про добавление поддержки С++ в 8-ой версии?
0
Предже всего, хочется в очередной раз подчеркнуть что поддержка С++ не будет включена в ReSharper 8 потому что она еще «сыровата» для полноценного продакшн-релиза.
(Поддержка C++ в ReSharper)
Вы это обещание имеете в виду, или какое другое?
+4
На правах примечания: скриншоты в разделе про архитектурные инструменты снимались на предрелизной версии ReSharper 8.0. С тех пор оформление графов зависимостей существенно изменилось. Чтобы посмотреть, как они выглядят сейчас, ознакомьтесь с этим видео.
+1
Пофиксили ли property with backing field, которые при рефакторинге создавались не рядом, а вверху класса?
0
Вы имеете в виду context action «To property with backing field»? В каком языке?
0
C#
В 6 версии емнип когда конвертилась auto property to property with backing field, то приватное поле ставилось рядом с пропертей. В 7 появилось упорядочивание, и приватное поле начало уезжать в начало класса, что чертовски неудобно.
В 6 версии емнип когда конвертилась auto property to property with backing field, то приватное поле ставилось рядом с пропертей. В 7 появилось упорядочивание, и приватное поле начало уезжать в начало класса, что чертовски неудобно.
0
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'а. Ну и из личного опыта — когда весь стейт типа в одном месте, это удобнее, чем внезапно обнаруживать поля где-нибудь между методов в совсем неожиданных местах.
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'а. Ну и из личного опыта — когда весь стейт типа в одном месте, это удобнее, чем внезапно обнаруживать поля где-нибудь между методов в совсем неожиданных местах.
+3
Для меня это самое backing field — это то что было auto property (public T Prop { get; set; }), а захотелось инициализацию, чтобы не мучиться с null. Всякое страшное использование нескольких пропертей на одном поле или проперти со страшной логикой — от лукавого и не про то.
Опять же имхо: когда близкие по семантике члены класса собраны вместе — это удобно, потому что когда правишь какой-то функционал, обращаешься именно к семантическому куску (ну например реализацию интерфейса удобно даже в #region заворачивать). Я когда-то пытался использовать «структурный» layout с группировкой по формальным признакам языка и понял, что это мне мешает, вместо того чтобы помогать. Бегание по всему файлу отнимает время, особенно если файл большой.
Опять же имхо: когда близкие по семантике члены класса собраны вместе — это удобно, потому что когда правишь какой-то функционал, обращаешься именно к семантическому куску (ну например реализацию интерфейса удобно даже в #region заворачивать). Я когда-то пытался использовать «структурный» layout с группировкой по формальным признакам языка и понял, что это мне мешает, вместо того чтобы помогать. Бегание по всему файлу отнимает время, особенно если файл большой.
0
Зачем вам бегать по файлу, если вы пользователь решарпера?
Интереса ради, Go to File Member, Go to Usages of Symbol, Alt+вверх/вниз — вы всем этим пользуетесь?
Интереса ради, Go to File Member, Go to Usages of Symbol, Alt+вверх/вниз — вы всем этим пользуетесь?
0
Нет, этим не пользуюсь.
Вместо этого у меня Go to Declaration (aka Ctrl+Click) и Find Usages. Наверное, это потому что я не помню, как у меня называются члены класса.
А никуда не ходить мне удобней, чем куда-то ходить, пусть даже это и просто.
Вместо этого у меня Go to Declaration (aka Ctrl+Click) и Find Usages. Наверное, это потому что я не помню, как у меня называются члены класса.
А никуда не ходить мне удобней, чем куда-то ходить, пусть даже это и просто.
0
Прошу прощения что отвечаю так поздно — только сейчас в очередной раз загуглив решение проблемы увидел комментарий. Дело в том что XAML разработчикам при создании ViewModel очень много приходится создавать property with backing field только для того что бы вызывать OnPropertyChanged для этого поля или дополнительно для нескольких полей. И таких полей приходится делать очень много. И при этом рефакторинг значительно усложняется если решили что это поле должно быть в другой VM. Вместо того что бы «вырезать»-«вставить» получаем «вырезать» «вставить» вернуться, найти это поле где оно было «вырезать», «вставить». Если решили удалить это проперти совсем — можно запросто забыть удалить поле наверху и т.д. и т.п. Да при построении логики это может быть и удобно когда поле генерируется на верху, но при активной работе с VM (а эта чуть ли не львиная доля работы для тех кто работает с XAML) это страшно неудобно и раздражает. То же самое касается Dependency Property. А в целом решарпером очень доволен — один из тех продуктов за который не жалко потраченных денег, но вот это «фича», которая по мнению JetBrains сделала нашу жизнь гораздо проще, субъективно снижает ценность продукта.
0
Всё это происходит отдельном потоке, поэтому пока ReSharper делает свою работу, вы можете продолжать писать код.
Когда же мы будем пить кофе, а Решарпер будет писать код, «в отдельном потоке»? :) Спасибо, замечательную тулзу!
+1
У меня в финальной версии все так же есть глюк, что в некоторых классах в саджесте нет полей и методов текущего класса. Локализовать к сожалению не могу :(
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ReSharper 8