Pull to refresh

Comments 77

Для C# теперь доступны два новых способа рефакторинга: введение переменной и инлайн переменной (удаление переменной).

На самом деле можно написать самому расширение — это не сложно с roslyn (хотя я писал и для R#-ра — тоже не особо сложно). Уверен что в будущем расширений будет как грязи (шаблон расширения для roslyn уже имеется «из коробки»).

Но есть и проблемы...
Интерфейс расширений выглядит async-хронным и студия выдаёт назойлевое окно аля «Ожидание бэкграунд операции» при показе подсказки и списка допустимых операций на рефакторинг (как на скрине в статье) при этом блокирует весь UI что мягко говоря сильно раздражает. Т.е. она ждёт пока все расширения не прочухаются и не вернут либо отложенную операцию с возможностью ее исполнить либо null, если операция к данному участку кода не применима. А т.к. определение возможности рефакторинга может быть не тривиальным, то это влечет боль…
«Надеюсь когда-нибудь появится возможность отказаться от решарпера.»
Чем он плох?
Я так подозреваю что за него нужно каждый год по 80-100 долларов отдавать (если одинокий разработчик\фрилансер) :)
А так заказчики не всегда хотят тратить деньги и покупать решарпер
На фоне цены за Ultimate версию, конечно меркнет. А вот на фоне нулевой цены за Express это примерно на 80-100 долларов дороже.
А разве решарпер работает с Express версией студии?
Ну так значит экономия будет ещё больше — можно будет не покупать студию вообще и пользоваться Express ;)
И как вы собираетесь пользоваться фишками Roslyn в Express, если там всё (кроме компилятора) для Pro и выше? Рефакторинг выпилен чуть менее, чем полностью, расширений нет, отладка ущербная. Если вам не хватает Express сейчас, то не будет хватать и в будущем, независимо от компилятора (если MS не начнёт внезапно перетаскивать фичи из старших версий, в чём я сильно сомневаюсь).
Ну так можно писать код в блокноте и компилировать из командной строки. Зачем вам студия тогда?
Мне не нравится что решарпер навязывает свое понимание «правильности». По крайней мере — на настройках по-умолчанию. Скажем, удаляет using System.Linq как неиспользуемый.

Там много подобного фашизма. Если работают два человека — с и без решарпера, то у человека с решарпером код человека без решарпера весь светится красненьким. И не потому что там что-то реально злые ошибки. А чисто потому что вот у решарпера есть какие-то свои понимания что можно делать в C#, а что как-бы не по-феншую.

Кроме этого, решарпер облегчает разбираться с хитросплетениями ООП — всяких фабрик и наследования. Что вроде и неплохо, но подталкивает к оверэнжинерингу. Я вижу код коллег с- и без решарпера. Без решарпера обычно пишут прямолинейнее и дубовее, с ним — c витьеватыми ООП-паттернами к месту и нет.
R# всего лишь инструмент, который можно очень тонко настроить под себя / под команду.

P.S. Всё зло от программистов :-)
Это понятно. Просто по моим наблюдениям множества людей любящих R#, и множество людей, делающих overengineered OOP — весьма неплохо коррелируют :)

R# — безусловно отличная штука, очень качественно сделанная. Но спрашивали за минусы.
Настраивать инструмент (Resharper), предназначенный для работы внутри другого инструмента (Visual Studio)? Может быть, написать ещё один специальный инструмент для настройки решарпера?
А что ж не так-то с настройкой инструмента внутри инструмента?
А ведь у решарпера есть плагины, у которых иногда бывают плагины…
А плагины для браузера вы никогда не настраивали?
Имхо, решарпер в данном случае поступает правильно. Если он подсвечивает какой-то код как «подозрительный», то это не потому, что ребятам из JetBrains так взбрело в голову по религиозным соображениям, а потому что этот код может вызывать неожиданные побочные эффекты или тормоза. Гуглеж по тексту сообщения как правило подробно рассказывает, почему ваша строчка подчеркнута.

Насчет System.Linq: а в чем проблема? Решарпер не нарушает экологию: даже если этот using вычищен как неиспользуемый, как только вы введете где-то имя метода из данного пространства имен (например Select), он тут же предложит добавить его обратно.
Решарпер даже договоренности (conventions) возводит в почти неприкасаемые правила: где студия молчит, решарпер светит красным, а идеалисты этого пережить не могут. Пример: товарищу нужно было десериализовать JSON, поля в нем с маленькой буквы. Чтобы десериализатор это съел, нужно написать в C#-классе свойства с маленькой буквы. У чувака не поднялась рука так грубо нарушить устои, и он написал десериализацию руками.

Насчет System.Linq — добавить extension-метод предложит только решарпер, студия не предложит. Т.е. пользователи решарпера подкладывают свинью тем, кто его не использует. Во-вторых оно просто вымораживает — я привык что linq всегда добавлен, и то что его удалили из using — последнее что я предположил. Сначала начал думать что у меня не так с типом, и почему он не реализует IEnumerable.
Не ругайте молоток за то, что вы промахнулись им мимо гвоздя и попали по пальцу. В вашем случае, мне кажется, проблема не в решарпере, а в отсутствии договоренности в команде и конфликте с лично вашими привычками («linq всегда добавлен»).
Про JSON — именуйте как надо, но ставьте сверху свойств атрибут [DataMember(Name=«ugly_JSON_name_here»)]
Это факап менеджмента. У них должен быть свой, менеджерский, решарпер.
В дополнение к вышесказанному всегда можно попросить решарпер временно помолчать.
А что у вас за десериалайзер такой, что не ест имена в camelCase?
Я так понял, это XmlSerializer или что-то похожее, где имена пропертей напрямую мапятся на имена атрибутов во входном потоке. Соответственно, если имя атрибута camelCased, то и имя проперти тоже должно быть camelCased.
Так не XML, а JSON же. Тот же Json.Net (который все нормальные люди используют) по умолчанию при десериализации делает case-insensetive поиск свойств, если нет точного совпадения.
Может, это коробочный DataContractJsonSerializer, или как его там?

(кстати, что забавно, сама студия использует Json.NET)
Да, и сериализация в camelCase настраивается в одну строчку.
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 добавляем неймспейсы, которые не хотим удалять и хотим иметь по умолчанию.
Решарпер конфигурится даже без открытия его настроек. Жмешь Alt+Enter на подсвеченном и там есть вариант изменить отношение решарпера к данному правилу. Часть правил можно легко перевести в незаметные подсказки.
> Насчет System.Linq — добавить extension-метод предложит только решарпер, студия не предложит.

Это как раз косяк студии. Кстати, ребята обещались его починить в 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, если что.
и не заплатить ни разу его достаточно большую цену.

если вы профессиональный программист, то для инструмента для работы цена у него мизерная.
Мне все инструменты для работы оплачивает компания. Но решарпер не хотят. :(
Почему Вы не обраились к разработчикам? Заведите баг на них!
Ну пробовал. Пишут: «В ваших результатах профилирования нифига не видно. Что вы делаете-то?» Пользуюсь решарпером, что.
А ссылочку на баг дайте, пожалуйста. Тогда смогу ответить предметно.
Наличие Решарпера существенно замедляет работу VS. Особенно на больших солюшенах это заметно. Также сильно увеличивается общее потребление оперативной памяти студией.
Аргумент, при слабом компе. Помниться без SSD на проекте с CMS-кой Ektron приходилось вообще отключать его в MSVS 2010. Все грузилось нереально долго.
С MSVS 2012 и на нормальной машине с SSD таких проблем не замечал. Хотя проекты были масштабнее.
Я работаю с солюшеном в примерно 200 проектов. Не знаю, что такое «нормальная машина», у меня рабочая с core i5, 8 гб озу и обычным винчестером. Считаю, что решарпер не должен являться причиной установки ssd. Снес его после пары лет мучений, сейчас наслаждаюсь высокой скоростью работы. Заодно больше пишу самостоятельно, меньше полагаюсь на автоматику.
Приличные SSD на 256 Гб стоят от $200. 16 гигабайт DDR3 — ещё $200.
Для любой конторы — это копейки, для разработчика, вобщем-то тоже.
Так что я не разделяю Ваше мнение.

Откуда вы знаете, что для кого копейки, а что нет? В большой организации часто бывает не так-то просто выбить себе через кучу бюрократии апгрейд компьютера.
Бывает, что приходилось ждать месяцами и годами, пока выделят деньги на большой монитор (это всего-то дешевый 22-дюймовый) в довесок к рабочему экрану в 15 дюймов (это для программиста-то!) на ноутбуке. А уж про доп.память и ССД вообще можно забыть. Я к тому, что случаи бывают разные…
1. Самому Вам что мешало купить?
2. Такая контора стоит того, чтобы в ней работать?
1. Может, я непонятно написал, но я был обычным работником, одним из сотен тысяч. Работником, а не владельцем или инвестором.
2. Какое-то время — определенно стоило. :)
Увы, 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]
Круто, не знал о такой фиче. Но всё равно, можно было в 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».
Синтаксис вида

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.
См. подробнее тут.
А, я просто немного отстал от жизни. В шарпе планировали делать нечто очень похожее, только писать надо так:
class Point(public int x, public int y) {}

Но теперь это внезапно решили выпилить две недели назад, и народ негодуэ.

Хотя для полного счастья еще нужна автогенерация Equals и GetHashCode. И ToString.
Да, идея с record — просто расширение концепции первичных конструкторов для немутабельных типов данных и pattern-matching-а
Так а разве в этом есть проблема? Кто не хочет использовать новую версию языка, не будет использовать. Разные версии рантаймов живут друг с другом без проблем. Это уж в десятки раз лучше, чем в Джаве, где изза обратной совместимости райнтами с лямбдами лет на 5 опоздали уже. А райнтайм информации о дженериках и до сих пор нет.
Иногда приходится мириться с тем, что у клиентов (Windows 7/Windows Server 2008R2) установлен только .NET 3.5, и, например, теми же тасками и async/await не попользоваться :(
Всё так делаете, спасибо за ссылку. Я привёл неудачный пример — в общем случае нужны были фишки .NET 4.5.
А в чём выражается «несовместимость с новой версией»?
Например, в использовании недокументированных особенностей предыдущей версии, которых нет в новой.
Я этот топик не оформлял как перевод, потому что хотел написать именно про Roslyn и C#, выжав информацию из пяти разных ссылок, а остальное затронуть мельком.
Sign up to leave a comment.

Articles