resharperでコードを壊すことはできますか？

Question

ソロショップの若い（ish）開発者として、私はResharperを学習ツールとミニQAとして大いに評価しました。つまり、Resharperはいくつかのケースでコードを破ることができます（おそらくエッジ）？そこ他の例も同様ですが、私はできるだけ多くの特定のインスタンスについての質問ではないのです>

this. is redundantとcatch is redundant

- 例えば

（下記参照）、R＃が継続的に私のことを示唆しています一般的なように。

誰にも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＃リファクタリングを見て、それを変更するように示唆しているコードを理解していないなら...それをしないでください。

Resharperはおそらく（私の経験では）正しいですが、あなたのコードをあなたが理解していないものに変えてしまったら、それを読めずにあなたに何の恩恵も与えません。

私は、ツールが何をするようにアドバイスしているのかを理解し、使用することを示唆しているコードと概念を研究することをお勧めします。それでは、あなたの状況において、与えられた提案が働くかどうかについて、判断を下すことができます。

このようにしてツールを使用して知識を深めていくと、最終的にR＃は、ソフトウェアの作成時にベストプラクティスとコーディングテクニックを思い出させるようになります。

理想的には、ツールを使用するほど、コードに最初のパスにコンセプトを組み込むことを開始する必要があるので、ツールに頼る必要が少なくなります。最初に提示した候補が必要なくなるはずです。

Answer 2

確かに！あなたはそれをリファクタリングしてコードを壊すために使うことができます。あなたはそれを使って何かの名前を変更し、あなたのコードを破ることができます。ここで重要なことは、resharperは実際にあなたのコードを壊すつもりはないということです...しかし、あなたがそれを不適切に使用することは確かに可能です！自分のコードを壊すような提案は一度もありませんでした。オプションパネルでresharperのほとんどの機能を無効にすることができます！

Answer 3

例外をキャッチすることは、この場合は「this」と同じように、冗長です。

キャッチは、キャ​​ッチしたときに実際に何かをした場合、それを再捕捉するのではなく、冗長性を失います。

Answer 4

あなたが持っている提案は、ReSharperによって提案されたデフォルト設定です。 Howerver、私は多くの提案が私の通常のコーディングスタイルと一致していないことを知っているので、私はそれを無効にします。 ReSharperの提案を同じ場所で簡単に無効にすることができます。

リファクタリングの良い点は、新しいC＃3.0の機能によってコードが単純化されることがあることに気付かず、ReSharperが非常に役に立ちます（匿名メソッドの代わりにラムダ式を使用するように頼んでください）。 ）。

Answer 5

コードを壊すことはありますが、まず問題の可能性があることを常に警告します。あなたはその提案を無効にすることによって、あなたの意志にresharperを曲げることができます。私は数年前から使用しており、テキストエディタの右上に緑色の矩形が表示されていると、ちょっとリラックスしています:)

Answer 6

ReSharperは完璧ではありません（すべてのソフトウェアの場合と同じです）。これは間違いなくバグがあり、間違っていてコードを壊すような提案を提供することがあります。しかし、私はこれらを非常にまれであると判断し、通常は非常にネストされた一般的なシナリオを必要とします。

一般に、ReSharperが何かを示唆しているなら、それは正しいです。この場合、catch文は効果的に何もしないので、ReSharperは正しいです。例外ターゲットのないスローは、元のオブジェクトを元に戻して新しい例外をスローするため、目に見える副作用がないはずです。

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

私はResharperが大好きですが、あなたのコードを壊す可能性があります。これは、ちょうど私に起こった：

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の提案は実行時例外を発生させたところ、私は今日に走った例です：

C(list.Sort); 

次のようになります。

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

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

static void C(Action action) 
{ 
} 

ReSharperのは、私は方法Bの内容が変化することを示唆したが、妥当な変更だが、それを呼び出す恐ろしいコードのため、実際にはSystem.ArgumentExceptionが発生した。