Комментарии 77
Для C# теперь доступны два новых способа рефакторинга: введение переменной и инлайн переменной (удаление переменной).
На самом деле можно написать самому расширение — это не сложно с roslyn (хотя я писал и для R#-ра — тоже не особо сложно). Уверен что в будущем расширений будет как грязи (шаблон расширения для roslyn уже имеется «из коробки»).
Но есть и проблемы...
Интерфейс расширений выглядит async-хронным и студия выдаёт назойлевое окно аля «Ожидание бэкграунд операции» при показе подсказки и списка допустимых операций на рефакторинг (как на скрине в статье) при этом блокирует весь UI что мягко говоря сильно раздражает. Т.е. она ждёт пока все расширения не прочухаются и не вернут либо отложенную операцию с возможностью ее исполнить либо null, если операция к данному участку кода не применима. А т.к. определение возможности рефакторинга может быть не тривиальным, то это влечет боль…
«Надеюсь когда-нибудь появится возможность отказаться от решарпера.»
Чем он плох?
Чем он плох?
Я так подозреваю что за него нужно каждый год по 80-100 долларов отдавать (если одинокий разработчик\фрилансер) :)
А так заказчики не всегда хотят тратить деньги и покупать решарпер
А так заказчики не всегда хотят тратить деньги и покупать решарпер
На фоне цены VS не меркнет?
На фоне цены за Ultimate версию, конечно меркнет. А вот на фоне нулевой цены за Express это примерно на 80-100 долларов дороже.
А разве решарпер работает с Express версией студии?
Честно говоря, думал что работает, а на самом деле нет:
Note: ReSharper doesn't work with Microsoft Visual Studio Express editionsВ любом случае, цена решарпера добавляет ощутимый процент к Professional версиии студии.
Ну так значит экономия будет ещё больше — можно будет не покупать студию вообще и пользоваться Express ;)
И как вы собираетесь пользоваться фишками Roslyn в Express, если там всё (кроме компилятора) для Pro и выше? Рефакторинг выпилен чуть менее, чем полностью, расширений нет, отладка ущербная. Если вам не хватает Express сейчас, то не будет хватать и в будущем, независимо от компилятора (если MS не начнёт внезапно перетаскивать фичи из старших версий, в чём я сильно сомневаюсь).
Ну так можно писать код в блокноте и компилировать из командной строки. Зачем вам студия тогда?
Мне не нравится что решарпер навязывает свое понимание «правильности». По крайней мере — на настройках по-умолчанию. Скажем, удаляет using System.Linq как неиспользуемый.
Там много подобного фашизма. Если работают два человека — с и без решарпера, то у человека с решарпером код человека без решарпера весь светится красненьким. И не потому что там что-то реально злые ошибки. А чисто потому что вот у решарпера есть какие-то свои понимания что можно делать в C#, а что как-бы не по-феншую.
Кроме этого, решарпер облегчает разбираться с хитросплетениями ООП — всяких фабрик и наследования. Что вроде и неплохо, но подталкивает к оверэнжинерингу. Я вижу код коллег с- и без решарпера. Без решарпера обычно пишут прямолинейнее и дубовее, с ним — c витьеватыми ООП-паттернами к месту и нет.
Там много подобного фашизма. Если работают два человека — с и без решарпера, то у человека с решарпером код человека без решарпера весь светится красненьким. И не потому что там что-то реально злые ошибки. А чисто потому что вот у решарпера есть какие-то свои понимания что можно делать в C#, а что как-бы не по-феншую.
Кроме этого, решарпер облегчает разбираться с хитросплетениями ООП — всяких фабрик и наследования. Что вроде и неплохо, но подталкивает к оверэнжинерингу. Я вижу код коллег с- и без решарпера. Без решарпера обычно пишут прямолинейнее и дубовее, с ним — c витьеватыми ООП-паттернами к месту и нет.
R# всего лишь инструмент, который можно очень тонко настроить под себя / под команду.
P.S. Всё зло от программистов :-)
P.S. Всё зло от программистов :-)
Это понятно. Просто по моим наблюдениям множества людей любящих R#, и множество людей, делающих overengineered OOP — весьма неплохо коррелируют :)
R# — безусловно отличная штука, очень качественно сделанная. Но спрашивали за минусы.
R# — безусловно отличная штука, очень качественно сделанная. Но спрашивали за минусы.
Настраивать инструмент (Resharper), предназначенный для работы внутри другого инструмента (Visual Studio)? Может быть, написать ещё один специальный инструмент для настройки решарпера?
Имхо, решарпер в данном случае поступает правильно. Если он подсвечивает какой-то код как «подозрительный», то это не потому, что ребятам из JetBrains так взбрело в голову по религиозным соображениям, а потому что этот код может вызывать неожиданные побочные эффекты или тормоза. Гуглеж по тексту сообщения как правило подробно рассказывает, почему ваша строчка подчеркнута.
Насчет
Насчет
System.Linq: а в чем проблема? Решарпер не нарушает экологию: даже если этот using вычищен как неиспользуемый, как только вы введете где-то имя метода из данного пространства имен (например Select), он тут же предложит добавить его обратно.Решарпер даже договоренности (conventions) возводит в почти неприкасаемые правила: где студия молчит, решарпер светит красным, а идеалисты этого пережить не могут. Пример: товарищу нужно было десериализовать JSON, поля в нем с маленькой буквы. Чтобы десериализатор это съел, нужно написать в C#-классе свойства с маленькой буквы. У чувака не поднялась рука так грубо нарушить устои, и он написал десериализацию руками.
Насчет System.Linq — добавить extension-метод предложит только решарпер, студия не предложит. Т.е. пользователи решарпера подкладывают свинью тем, кто его не использует. Во-вторых оно просто вымораживает — я привык что linq всегда добавлен, и то что его удалили из using — последнее что я предположил. Сначала начал думать что у меня не так с типом, и почему он не реализует IEnumerable.
Насчет System.Linq — добавить extension-метод предложит только решарпер, студия не предложит. Т.е. пользователи решарпера подкладывают свинью тем, кто его не использует. Во-вторых оно просто вымораживает — я привык что linq всегда добавлен, и то что его удалили из using — последнее что я предположил. Сначала начал думать что у меня не так с типом, и почему он не реализует IEnumerable.
Не ругайте молоток за то, что вы промахнулись им мимо гвоздя и попали по пальцу. В вашем случае, мне кажется, проблема не в решарпере, а в отсутствии договоренности в команде и конфликте с лично вашими привычками («linq всегда добавлен»).
В дополнение к вышесказанному всегда можно попросить решарпер временно помолчать.
Промахнулся, ответ рядом.
А что у вас за десериалайзер такой, что не ест имена в camelCase?
Я так понял, это XmlSerializer или что-то похожее, где имена пропертей напрямую мапятся на имена атрибутов во входном потоке. Соответственно, если имя атрибута camelCased, то и имя проперти тоже должно быть camelCased.
Json.NET. Он ест, там настройка есть. Товарищ может не знал просто.
Во-первых Inconsistent Naming по умолчанию всегда warning, а не error, т.е. он не красный, если его не сделали ошибкой явно в настройках. Во-вторых есть как минимум 3 решения:
1) Выключить временно с помощью коммента // ReSharper disable once InconsistentNaming
2) Изменить naming conventions в настройках
3) Дописать к названию файла Generated.cs, тогда инспекции на нем отключаться. Либо добавить его явно в секцию Code Inspection → Generated Code
1 и 2 делаются прямо из редактора кода двумя нажатиями.
Насчет usings: в настройках Code Editing → C# → Namespace Imports добавляем неймспейсы, которые не хотим удалять и хотим иметь по умолчанию.
1) Выключить временно с помощью коммента // ReSharper disable once InconsistentNaming
2) Изменить naming conventions в настройках
3) Дописать к названию файла Generated.cs, тогда инспекции на нем отключаться. Либо добавить его явно в секцию Code Inspection → Generated Code
1 и 2 делаются прямо из редактора кода двумя нажатиями.
Насчет usings: в настройках Code Editing → C# → Namespace Imports добавляем неймспейсы, которые не хотим удалять и хотим иметь по умолчанию.
Решарпер конфигурится даже без открытия его настроек. Жмешь Alt+Enter на подсвеченном и там есть вариант изменить отношение решарпера к данному правилу. Часть правил можно легко перевести в незаметные подсказки.
> Насчет System.Linq — добавить extension-метод предложит только решарпер, студия не предложит.
Это как раз косяк студии. Кстати, ребята обещались его починить в Roslyn.
Кстати, сама студия тоже замечательно удаляет System.Linq из using по «Remove and Sort Usings», безо всякого решарпера.
Это как раз косяк студии. Кстати, ребята обещались его починить в Roslyn.
Кстати, сама студия тоже замечательно удаляет System.Linq из using по «Remove and Sort Usings», безо всякого решарпера.
Как показывает практика, если какая-то функциональность выключена по умолчанию, то вероятность, что о ней узнают пользователи примерно равна 0, при этом для некоторого множества пользователей она все же может быть полезна. Любые неудобные инспекции можно выключить даже не заходя в настройки (Alt-Enter на подсветке в коде, и выбрать нужное меню)
Чем он хорош? Я его и сейчас не использую — примочка для нубов.
Я очень люблю решарпер. При правильной настройке он почти идеален в плане поиска ошибок и подсказок. А через превью версии и триалы можно использовать его очень долго и не заплатить ни разу его достаточно большую цену.
Проблема в том что он тормозной. Я имею ввиду, он же просто ОЧЕНЬ тормозной!
У меня с отключеным Solution-wide analysis он умудряется практически постоянно в бекграунде отъедать несколько ядер процессора сразу на 100%, особенно если быстро бегать по солюшену (а с Ctrl+T и Ctrl+; и несколькими мониторами получается очень быстро). А если работать с ноутбука не от сети, то батарейку, держущую 11 часов игры в шахматы в браузере, можно просадить за полтора часа решарпера. Спасает только режим сохранения энергии (ограничение процессора в 5%) или заветная кнопочка Suspend Now.
Может это такое происходит из-за огромного проекта, bin после билда 150 мегабайт. Но Solution-wide analysis-то отключен!
У меня последняя версия R# 8.2.1 и последняя VS 2013.2, если что.
Проблема в том что он тормозной. Я имею ввиду, он же просто ОЧЕНЬ тормозной!
У меня с отключеным Solution-wide analysis он умудряется практически постоянно в бекграунде отъедать несколько ядер процессора сразу на 100%, особенно если быстро бегать по солюшену (а с Ctrl+T и Ctrl+; и несколькими мониторами получается очень быстро). А если работать с ноутбука не от сети, то батарейку, держущую 11 часов игры в шахматы в браузере, можно просадить за полтора часа решарпера. Спасает только режим сохранения энергии (ограничение процессора в 5%) или заветная кнопочка Suspend Now.
Может это такое происходит из-за огромного проекта, bin после билда 150 мегабайт. Но Solution-wide analysis-то отключен!
У меня последняя версия R# 8.2.1 и последняя VS 2013.2, если что.
Наличие Решарпера существенно замедляет работу VS. Особенно на больших солюшенах это заметно. Также сильно увеличивается общее потребление оперативной памяти студией.
Аргумент, при слабом компе. Помниться без SSD на проекте с CMS-кой Ektron приходилось вообще отключать его в MSVS 2010. Все грузилось нереально долго.
С MSVS 2012 и на нормальной машине с SSD таких проблем не замечал. Хотя проекты были масштабнее.
С MSVS 2012 и на нормальной машине с SSD таких проблем не замечал. Хотя проекты были масштабнее.
Я работаю с солюшеном в примерно 200 проектов. Не знаю, что такое «нормальная машина», у меня рабочая с core i5, 8 гб озу и обычным винчестером. Считаю, что решарпер не должен являться причиной установки ssd. Снес его после пары лет мучений, сейчас наслаждаюсь высокой скоростью работы. Заодно больше пишу самостоятельно, меньше полагаюсь на автоматику.
Приличные SSD на 256 Гб стоят от $200. 16 гигабайт DDR3 — ещё $200.
Для любой конторы — это копейки, для разработчика, вобщем-то тоже.
Так что я не разделяю Ваше мнение.
Для любой конторы — это копейки, для разработчика, вобщем-то тоже.
Так что я не разделяю Ваше мнение.
Откуда вы знаете, что для кого копейки, а что нет? В большой организации часто бывает не так-то просто выбить себе через кучу бюрократии апгрейд компьютера.
Бывает, что приходилось ждать месяцами и годами, пока выделят деньги на большой монитор (это всего-то дешевый 22-дюймовый) в довесок к рабочему экрану в 15 дюймов (это для программиста-то!) на ноутбуке. А уж про доп.память и ССД вообще можно забыть. Я к тому, что случаи бывают разные…
Увы, SSD не лечит проблему с памятью. Причем все усугубляется тем, что сама VS 32-битная, и неважно, сколько у вас памяти всего — все равно вы сначала упретесь в те самие пресловутые 2Gb.
Вопрос про скорость спорный. Да решарпер замедляет работу VS, но при этом увеличивает скорость выполнения некоторых рутинных операций. Моё ИМХО — с решарпером быстрее работать
For web and console projects, the build will not generate any packages or dlls. When you deploy the project to the file system, you will see that the source code will be copied as well. The projects are compiled and run dynamically.
No build needed for changes to appear in browser
Thanks to the Rosyln compiler, if you change ".cs” files or project.json file and want to see the change in the browser, you don’t need to build the project any more. Just refresh the browser.
Интересно, на сколько всё станет быстрее.
What is it? Here’s the scenario
Consider getting the grandchild of a parent object like this:
var g1 = parent.child.child.child;
Okay, so, this is some poor coding because the value of child could be null. If I attempt to ask for the value of child and the containing object is null, a NullReferenceException will be raised and my app will crash.
conditional access operator это конечно хорошо, но когда уже появится возможность узнать на каком child выкидывается NullReferenceException.
Поставив в .NET 4.5 и VS 2013 брейкпоинт на этой строке и сделав Step Over, в Autos/Locals вы найдете промежуточные результаты:
parent.child [Child]
parent.child.child [Child]
parent.child.child.child [null]
parent.child [Child]
parent.child.child [Child]
parent.child.child.child [null]
Круто, не знал о такой фиче. Но всё равно, можно было в nullrefexception писать хотябы имя разыменовываемой переменной. Ради стэктрейса.
Про брейкпоинт спасибо, возьму на вооружение.
Про брейкпоинт спасибо, возьму на вооружение.
Ну это скорее проблема не исключения, а самих брейкпоинтов и стек трейса — одного лишь номера строки недостаточно для определения источника исключения. Для решения достаточно будет возможности ставить брейкпоинт не на строку, а на оператор, а в стек трейсе писать ещё и номер столбца.
Тогда в общем случае если кто-то из вызванных функций в выражении
Тогда в общем случае если кто-то из вызванных функций в выражении
A().B().C().D().E() кидает исключение, то в стек трейсе будет видно, в каком месте исключение появилось, а приаттаченный дебаггер остановится не на строке, а на столбце с точкой, например.
Новая Visual Studio — значит скоро новый SharpDevelop.
Ко всем: а вам не кажется, что .NET вообще и C# в частности развиваются слишком уж быстро? Многие большие конторы ну очень туго внедряют последние версии и технологии. А уж если в проекте используются компоненты (свои или чужие), не совместимые с новой версией, то совсем плохо.
Наоборот, кажется, что слишком медленно. Хочется немутабельных структур данных и хоть какой-то поддержки pattern-matching, а они это не раньше 2015 года обещают. И вообще, учитывая, что сейчас можно будет на K Runtime деплоить с приложением свою версию дотнета, не должно быть проблем с внедрением.
Что вы имеете в виду под немутабельными структурами данных? Immutable collections уже есть в NuGet, а возможность быстро объявлять immutable классы и структуры, как я понимаю, входит в primary constructors, которые на roslyn.codeplex.com уже отмечены как «done».
Синтаксис вида
Разворачивающийся в конструкцию вида
Что помимо возможности не писать кучу лишнего даёт однозначное сопоставление параметров конструктора и свойств типа, что в свою очередь позволяет нормально делать по таким типам pattern-matching.
См. подробнее тут.
record class Point(int x, int y) {}
Разворачивающийся в конструкцию вида
class Point
{
public int X {get; private set;}
public int Y {get; private set;}
[PrimaryConstructor]
public Point ([ValueFor("X")]int x, [ValueFor("Y")]int y)
{
X = x;
Y = y;
}
}
Что помимо возможности не писать кучу лишнего даёт однозначное сопоставление параметров конструктора и свойств типа, что в свою очередь позволяет нормально делать по таким типам pattern-matching.
См. подробнее тут.
А, я просто немного отстал от жизни. В шарпе планировали делать нечто очень похожее, только писать надо так:
Но теперь это внезапно решили выпилить две недели назад, и народ негодуэ.
Хотя для полного счастья еще нужна автогенерация Equals и GetHashCode. И ToString.
class Point(public int x, public int y) {}
Но теперь это внезапно решили выпилить две недели назад, и народ негодуэ.
Хотя для полного счастья еще нужна автогенерация Equals и GetHashCode. И ToString.
Так а разве в этом есть проблема? Кто не хочет использовать новую версию языка, не будет использовать. Разные версии рантаймов живут друг с другом без проблем. Это уж в десятки раз лучше, чем в Джаве, где изза обратной совместимости райнтами с лямбдами лет на 5 опоздали уже. А райнтайм информации о дженериках и до сих пор нет.
А в чём выражается «несовместимость с новой версией»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доступна превью новой версии Visual Studio, с Roslyn и C# 6