Может ли изменить ваш код?

Question

Как молодой (иш) разработчик в сольном магазине, я очень благодарен 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; 
     } 
    } 

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

Ловля вашего исключения только для его броска, безусловно, избыточна, то же самое с «этим» в этом случае.

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

Самая большая проблема, с которой я когда-либо сталкивался, - это когда я занимаюсь рефакторингом, и он не действует повсеместно, что нужно. Это происходит в большом проекте, где у меня могут не быть всех ссылочных компонентов, загружаемых в одно решение в любой момент времени, или когда я регенерирую из местоположения, которое довольно далек от объявления. Просто будьте осторожны, и все будет хорошо.

Answer 8

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

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

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

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

Answer 9

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

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

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

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

Answer 10

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

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

Но Resharper хочет меня, чтобы преобразовать лямбда-группы методов, например, так:

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

Here's why it doesn't work и это не вина ReSharper, но вы все равно должны быть осторожными ,

Answer 11

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

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

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

Answer 12

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

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.