_FR>Потому что для меня это не пустяки. А для плагина к студии (да и вообще к чему-либо) должно быть пустяком не менять безвозвратно что-либо привычное. Снипеты и #endregion — ладно, без этого бы купил бы. А вот то, что не поддерживается мой любимый способ форматирования — неприятно.
При всём моём уважении к вам, нытьё о скобочка и пробелах — детство.
Сколько раз вам приходилось менять стиль форматирования? И как быстро вы читали\писали по новому? Так всё сложно было?
Вот тут подумалось, как же вас наверное плющит когда вы читаете разные примеры в инете. Там как только не наформатируют Не плющит ? Так может не так уж это и важно где пробельчик стоит ?

Здравствуйте, nikov, Вы писали:

L>>О каких варнингах речь? О тех что Visual Studio и так выдаёт при компиляции?

N>Во-первых, решарпер выдает гораздо больше ворнингов (например, он может отловить большинство мест в коде, где может появиться NullReferenceException), а во вторых, они показываются в фоновом режиме сразу в процессе написания кода, без всякой компиляции (код вообще может быть еще не компилируемым).

Смысл моего поста был в том, что по сути — лично мне не очень важно когда появляются warning'и, по вводу кода или при компиляции.

Но ответ — да, Warning'и выдаёт.

Вообще пока впечатления о продекте положительные:
Плюсы:
1. Поддерживает С++, ASP.NET, XML
2. Действительно не давит функционал Visual Studio
3. UI фишки удобнее и более продуманы. На пример, при наведении на пукт меню показывает в коде как оно будет в итоге.

Минусы:
1. По функционалу, судя по всему уступает ReSharper'у. Если сравнивать в лоб — фича к фиче. С другой стороны есть несколько прикольных вещей.


В общем у меня на работе ReSharper, а дома этот продукт — посмотрим, кто победит.

Здравствуйте, lboss, Вы писали:

L>В общем у меня на работе ReSharper, а дома этот продукт — посмотрим, кто победит.

Просьба по результату отписаться.

Здравствуйте, _FRED_, Вы писали:


_FR>"Первый пункт" ИМХО надо делать так, что бы не "по дефолту устраивало среднестатистического пользователя", а что б "по-дефолту не отличалось от поведения студии".
согласен на все 100
У нас в команде у всех одинаковая настройка форматирование и все код форматируют, но тут приходят пара человек с R#, который по умолчанию форматирует немного по другому. Люди бесятся и кричат, что им не нужен никакой R#.
Я потратил около получаса на то, что бы настроить форматирование такое же как в студии, и то не уверен, что все пункты охватил.

На мой взгляд нужно что бы не настройки брались, а поведение форматтера. Т.е. смотрим какие настройки студии, при этом знаем как себя ведет VS, и под это поведение сделать настройки R#, так что бы прогон VS форматера после R# ничего не менял и наоборот.

Но в любом случае спасибо за хороший продукт.

Здравствуйте, xvost, Вы писали:

_FR>>Спасибо! http://youtrack.jetbrains.net/issue/RSRP-166353 там ссылка на наш же с тобой разговор на эту тему

X>В будущем это будем лечить......
X>Хотя я позволю себе высказать маленькое ИМХО что ты просто не умеешь готовить кошек в этом месте
X>Дело в том что в окошке metadata view полностью доступен весь РеШарперный функционал, в том числе и FileStructure и Goto Member
X>Поэтому смотреть глазами на эту простыню нет необходимости

ОК, попробую привыкнуть, расскажу. Но всё равно некрасиво _заставлять_ меня это делать.

_FR>>Не в первый раз пытаюсь [кричать]! Но как-то редко приводит к чему-то, вера пропадает. Потом появляется снова, снова кричу.

X>Приводит.
X>Меняется наш приоритет в ряде вопросов.

Отлично

_FR>>"Первый пункт" ИМХО надо делать так, что бы не "по дефолту устраивало среднестатистического пользователя", а что б "по-дефолту не отличалось от поведения студии".

X>Сам понимаешь, что это эквивалентно "по дефолту РеШарпер выключен"
X>То, что в ряде мест РеШарпер не пассивен, а интрузивно влияет на код — это основа целого спектра функционала

Гхм, хорошо. Но, с другой стороны это приводит к тому, что когда вы напрочь (ненастраиваемо обратно) лишаете пользователя привычного [без решарпера] функционала, вы этого (1) не замечаете и (2) вам приходится годами доказывать, что это нужно. Зачем давать повод для споров, ибо независимо от правоты, такие споры утомляют и вас, и пользователей?

А вот если бы вы немного изменили свой подход к вопросу интеграции, выбрав вектор возможности настройки решарпера таким образом, что бы после установки (или первого запуска) могли бы [по специальной команде пользователя] зачитать настройки студии (в том числе форматирования) и "встать" так, что бы только добавить функционал, не изменив существующего, вот это было бы "как надо" с моей точки зрения.

Здравствуйте, AndrewVK, Вы писали:

_FR>>Я такогского не хочу.

AVK>Я тут ХЗ, этот код писали до меня, но это 100% сделано специально. А в чем проблема то? Неужели настолько важно писать комментарий после открывающей скобки блока? ИМХО выглядит это по уродски.

Ну а по-моему, по-уродки это когда коментарий, имеющий отношение к оператору написан выше или ниже его, а не рядом.

// Тут не хочу
if(value == null) { // Мне удобно видеть коммент здесь
  // Тут тоже не хочу
}//if

Думаешь, спор по этому вопросу нас куда-то приведёт?

_FR>> Но прпробуем так: (и случай выше покрывается): настройка "ни как не форматировать и не передвигать однострочные комментарии после открывающей или закрывающей фигурной [операторной] скобки"? A-la "Don't indent comments started after a brace ("{" or "}")".

AVK>Все равно как то вычурно. ИМХО, у 99% пользователей подобная настройка вызовет недоумение.

Хорошо. Тогда мне подойдёт настройка "Don't indent comments after somethink." — которая запрещала бы решарперу вообще изменять положение коментария, если перед ним есть вообще какой0либо не пробельный символ.

    // Это нужно будет сдвинуть влево
  if(value == null) { // Это двигать не нужно
  // Это нужно сдвинуть вправо
  }//Это тоже двигать не нужно

AVK>Проверять каким образом? В виде демона?

Давай пока отложим, раз уж я решарпер установил, поковыряюсь по сам, тогда быть может более конкретно смогу сформулировать. В любом случае это совсем не критично.

Здравствуйте, Dog, Вы писали:

_FR>>Потому что для меня это не пустяки. А для плагина к студии (да и вообще к чему-либо) должно быть пустяком не менять безвозвратно что-либо привычное. Снипеты и #endregion — ладно, без этого бы купил бы. А вот то, что не поддерживается мой любимый способ форматирования — неприятно.
Dog>При всём моём уважении к вам, нытьё о скобочка и пробелах — детство.
Dog>Сколько раз вам приходилось менять стиль форматирования? И как быстро вы читали\писали по новому? Так всё сложно было?
Dog>Вот тут подумалось, как же вас наверное плющит когда вы читаете разные примеры в инете. Там как только не наформатируют Не плющит ? Так может не так уж это и важно где пробельчик стоит ?

Давай ты со своим мнением по поводу того, от чего меня плющит и о чём мне стоит вопить не будешь делиться на людях? Я уж как-нибудь сам разберусь.

Здравствуйте, _FRED_, Вы писали:

_FR>Думаешь, спор по этому вопросу нас куда-то приведёт?

Да дело то не в споре, а в том чтобы найти золотую середину. С точки зрения реализации тут проблем никаких.

AVK>>Все равно как то вычурно. ИМХО, у 99% пользователей подобная настройка вызовет недоумение.

_FR>Хорошо. Тогда мне подойдёт настройка "Don't indent comments after somethink." — которая запрещала бы решарперу вообще изменять положение коментария, если перед ним есть вообще какой0либо не пробельный символ.

Ну, у меня локально лежит версия, которая управляемо либо один пробел вставляет, либо ни одного. Думаю, коммитить или нет.

AVK>>Проверять каким образом? В виде демона?

_FR>Давай пока отложим, раз уж я решарпер установил, поковыряюсь по сам, тогда быть может более конкретно смогу сформулировать. В любом случае это совсем не критично.

Да мы все равно вчера отбранчили 5.0, так что теперь торопиться некуда, как раз самое время фичи попланировать.

К разработчикам ReSharper:
Вспомнил одну вещь которая мне мешает: можно ли как-то отключить автовставку закрывающей кавычки? Я вижу только опцию которая либо включает автовставку закрывающих скобок и кавычек, либо отключает. А мне хочется чтобы закрывающие скобки автоматом вставлялись, а кавычки — нет.

AVK>Что конкретно не устраивает?
Из форматирования. Это

Автор: Dog
Дата: 06.06.08

так и не сделали. Можно чтобы == никогда не переносило?

Здравствуйте, Dog, Вы писали:

AVK>>Что конкретно не устраивает?
Dog>Из форматирования. Это

Автор: Dog
Дата: 06.06.08

так и не сделали. Можно чтобы == никогда не переносило?

С переносом длинных строк пока сложно.

AVK>>>Что конкретно не устраивает?
Dog>>Из форматирования. Это

Автор: Dog
Дата: 06.06.08

так и не сделали. Можно чтобы == никогда не переносило?
AVK>С переносом длинных строк пока сложно.
Тут не про длинные строки, а про операторы сравнения в условиях. Вроде хвост говорил что поправит. Но давно это было. Как раз после того как это сделали.

if (var1 == null
        || var2 == null)
{
    Foo();
}

Но стало переносить и "==" иногда

Здравствуйте, Dog, Вы писали:

Dog>Тут не про длинные строки, а про операторы сравнения в условиях.

Ну так решарпер такое может переносить, только если строка слишком длинная.

Dog>>Тут не про длинные строки, а про операторы сравнения в условиях.
AVK>Ну так решарпер такое может переносить, только если строка слишком длинная.
хм, если встречу пример отпишу. Я уже привык к этому

А>согласен на все 100
А>У нас в команде у всех одинаковая настройка форматирование и все код форматируют, но тут приходят пара человек с R#, который по умолчанию форматирует немного по другому. Люди бесятся и кричат, что им не нужен никакой R#.
А>Я потратил около получаса на то, что бы настроить форматирование такое же как в студии, и то не уверен, что все пункты охватил.
А почему бы всей команде не перейти на использование решарпера ?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Dog, Вы писали:

Dog>>Тут не про длинные строки, а про операторы сравнения в условиях.

AVK>Ну так решарпер такое может переносить, только если строка слишком длинная.

 using (var dialog = new SaveFileDialog())
 {
   if (dialog.ShowDialog() == DialogResult.OK) {}
 }

 using (var dialog = new SaveFileDialog())
 {
    if (dialog.ShowDialog()
        == DialogResult.OK) {}
 }

Настройки дефолтные.

Здравствуйте, Dog, Вы писали:

Dog>А почему бы всей команде не перейти на использование решарпера ?
А почему все должны переходить на R#? Я всегда был против принудительного использования инструментов. Мне абсолютно не нужен разлад в команде и отмазы типа я не успел, т.к. R# глючит, тормозит, etc (нужное подчеркнуть). Тема навязывания (не R#, а вообще) уже неоднократно обсуждалась, еси интересно чем заканчивается — поищите в форуме "О работе"

Но в любом случае сначала всегда кто-то что-то пробует и потом убеждает других начать использовать.
Но очень сложно убеждать людей у которых сложилось негативное мнение о продукте из-за таких вот мелочей.

Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте,

MC>С удивлением, уже не в первый раз, обнаруживаю что некоторые разработчики не используют решарпер, причем пробовали его (иногда даже несколько раз), но отказались. Мне кажется это прекрасный продукт, и мне только в кошмарном сне может приснится, что мне придется без него работать.

Легко. Вернее так: совсем без него трудно, но постоянно с ним — вообще невозможно на наших солюшинах. Так что периодически его подключаем для чистки кода, а основная работа без него.

Здравствуйте, AndrewVK, Вы писали:


AVK>Верный никакой — вывода просто нет. Просто поделился информацией. И касаемо перформанса — мы работаем над ним постоянно. Вот прямо вчера обсуждали еще одну особенность фреймворка в этом плане. К сожалению, далеко не все в нашей власти — очень многие тормоза вызваны студией, даже если на первый взгляд кажется, что виноват решарпер.

Но сама-то студия без него просто летает.

Здравствуйте, alvas, Вы писали:
A>Так прорекламируй мне R#. Может и мне захочется. Я серьезно.
Да, еще вспомнил, что в решарпере мне приглянулся TODO-лист. Все просто: комментарии с TODO, NOTE, BUG (возможно, еще какие-то), и NotImplementedException (возможно, что-то еще) подсвечиваются в файле синим, видны на полосочке рядом со скроллом, а также со всего солюшена собираются в удобный список с группировкой и вроде еще фильтрацией. Весьма удобный список оставлять себе напоминалки в коде.