Может ли резарпер сломать твой код? - PullRequest
3 голосов
/ 12 июня 2009

Будучи молодым разработчиком в магазине соло, я очень ценю Resharper как инструмент обучения и мини-QA. При этом, может ли Resharper нарушить ваш код в некоторых случаях (возможно, в крайнем случае)?

Например (см. Ниже), R # постоянно предполагает, что мой ->

this. is redundant и catch is redundant

Есть и другие примеры, но я не столько спрашиваю о конкретном случае, сколько в целом.

Кто-нибудь имел предложение R # перерыв их код? Если так, то чем они и были для меня важнее всего; Что я могу искать, чтобы понять, действительно ли это дает мне плохой совет?

 private void LoadMyForm(DataRow row)
    {

        try
        {
            this.tbxFirstName.Text = row["FirstName"].ToString();
            this.tbxLastName.Text = row["LastName"].ToString();
            tbxMiddleName.Text = row["MiddleName"].ToString();
            tbxPersonID.Text = row["PersonID"].ToString();
            tbxSSN.Text = row["SSN"].ToString();
            tbxEmailAddress.Text = row["EmailAddress"].ToString();
        }
        catch (Exception)
        {
            throw;
        }
    }

Ответы [ 12 ]

13 голосов
/ 12 июня 2009

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

Улов перестал бы быть излишним, если бы вы действительно что-то сделали, когда поймали его, вместо того, чтобы бросать его.

8 голосов
/ 15 июня 2009

По моему мнению, Resharper следует рассматривать как расширение ваших личных знаний о C # и принципах разработки программного обеспечения в целом. Если вы посмотрите на предложенный рефакторинг R # и не понимаете код, который предлагает изменить его на ... НЕ ДЕЛАЙТЕ ЭТОГО.

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

Я бы порекомендовал исследовать код и концепцию, которую он предлагает использовать, и постараться понять, что этот инструмент советует вам делать. Только тогда вы сможете принять решение о том, работает ли данное предложение в ВАШЕЙ ситуации.

Если вы продолжите в том же духе и будете использовать инструмент для расширения своих знаний, то в конечном итоге R # станет мягким напоминанием о передовых практиках и методах кодирования при написании программного обеспечения.

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

6 голосов
/ 12 июня 2009

ReSharper не является непогрешимым. Это не то же самое, что кто-то сидит с тобой и читает твой код. Это делает все возможное. Тем не менее, выгоды от R # намного перевешивают потери, и никто не должен слепо следовать советам R #.

R # однажды предложил изменение в моем коде, которое определенно ломалось. У меня был (несколько псевдокод):

var submitBtn = (Button)Controls.FindControl(blahblahblah);

R # сказал мне обернуть его в using. Это разрушит мой элемент управления до того, как я закончу с его областью действия. Конечно, это была меньшая ошибка R #, чем моя собственная, но ты пойдешь.

4 голосов
/ 12 июня 2009

ReSharper не идеален (как в случае со всем программным обеспечением). Он определенно содержит ошибки и иногда предлагает неправильные предложения, которые могут испортить ваш код. Однако я обнаружил, что это очень редко и обычно включает в себя несколько очень вложенных общих сценариев.

В общем, если ReSharper предлагает что-то, это правильно. В этом случае ReSharper верен, потому что оператор catch эффективно ничего не делает. Бросок без цели исключения будет отбрасывать оригинал против броска нового исключения, и, следовательно, не должно быть никаких видимых побочных эффектов.

3 голосов
/ 12 июня 2009

Конечно! Вы можете использовать его для рефакторинга и взлома вашего кода. Вы можете использовать это, чтобы переименовать что-то через ваше решение и заставить его сломать ваш код. Ключевым моментом здесь является то, что Resharper на самом деле не собирается нарушать ваш код ... но использование его не по назначению, безусловно, может! У меня никогда не было проблем с предложениями, нарушающими мой код. Вы можете отключить почти все функции resharper через панель настроек!

2 голосов
/ 15 июня 2009

Единственный способ узнать, какие советы следует и не следует принимать во внимание, - это опыт.

Лично в качестве стиля кодирования мне нравится ссылаться на все переменные-члены как this.something, поскольку это упрощает идентификацию переменных-членов и локальных полей при просмотре кода, другие люди могут не согласиться по разным причинам.

Кроме того, ловить и перебрасывать одно и то же исключение не только избыточно, но на самом деле может быть довольно плохой идеей, поскольку перехват и перебрасывание не то же самое, что и не перехватывать в первую очередь и может привести к ваш стек вызовов. Смотри http://weblogs.asp.net/fmarguerie/archive/2008/01/02/rethrowing-exceptions-and-preserving-the-full-call-stack-trace.aspx

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

1 голос
/ 04 января 2014

Я люблю Resharper, но да, это может нарушить ваш код. Это только что случилось со мной:

new string[]{"Some+Nested+Type"}.Select(x => Type.GetType(x)); // this works

Но Решарпер хочет, чтобы я преобразовал лямбду в группу методов следующим образом:

new string[]{"Some+Nested+Type"}.Select(Type.GetType); // this doesn't work

Вот почему это не работает и это не вина Решарпера, но вы все равно должны быть осторожны.

1 голос
/ 12 июня 2009

Полученные рекомендации являются настройками по умолчанию, предложенными ReSharper. Однако я считаю, что многие предложения не соответствуют моему обычному стилю кодирования, поэтому я отключаю его. Вы можете легко отключить его с предложением ReSharper в том же месте.

Хорошая вещь о рефакторинге заключается в том, что иногда вы не знаете, что некоторые новые функции C # 3.0 могут упростить ваш код, и ReSharper очень полезен в этом отношении (прошу вас использовать лямбда-выражение вместо анонимного метода ....) .

0 голосов
/ 24 ноября 2015

Да, вот пример, с которым я столкнулся сегодня, когда предложение Решарпера вызвало исключение времени выполнения:

static void A()
{
    B(null);
}

static void B(List<int> list)
{
    C(() => list.Sort());
}

static void C(Action action)
{
}

ReSharper предложил изменить содержание метода B на:

    C(list.Sort);

Выглядит как разумное изменение, но из-за ужасного кода, который его вызывает, оно фактически вызвало System.ArgumentException.

0 голосов
/ 25 августа 2015

Когда он предлагает использовать инициализаторы объектов, он готов сделать что-то вроде:

Foo ThisFoo = new Foo() {Name = Name;}

На самом деле я не скомпилировал это, чтобы увидеть, может ли компилятор увидеть, что Name - это переменная, отличная от Name, потому что даже если она работает, я считаю ее неприемлемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...