2010-12-30 3 views
8

私はちょうどResharperを使用して、私はC#でコード化する方法がわからないように感じました。それは私に多くの示唆を与えました。それらのいくつかは以下のとおりです。私の変数と入れて変換)Cシャープコードクリーンアップ:resharper

this.Loaded += MainPage_Loaded; 

3に

var o = new SomeObject() 

2)this.Loaded += new RoutedEventHandler(MainPage_Loaded);

1)SomeObject o = new SomeObject();

ReSharperのは、に変換されます_をすべてのインスタンス変数の前に追加します。

4)クラスの親の名前を削除する。私はこれをSilverlightでテストしました。

public partial class MainPage 

5)インスタンス変数

this.variable = somevalue 

variable = somevalue 

に置き換えるに

public partial class MainPage : UserControl 

これらのすべてが本当に必要か?それは本当に私のプログラムの効率に影響を与えるでしょうか?私はクラス名をvarというキーワードに置き換えることで何がうまくいくのかを意味します。結局、varもコンパイル時にクラス名に置き換えられます。 にはがプログラムされているか、これらのことが実際に何らかの形で影響を及ぼしているからですか?

+0

私は本当にポイント4について疑問を抱いています。 –

+3

@Madhur:それは、部分クラスの他の部分がUserControlから継承すると宣言されている場合にのみ行います。 –

+0

@マドゥア:ジョーのコメントに+1。このクラスが「部分的」であることを忘れないでください。 –

答えて

8

この動作は、このいずれかを好きではないがReSharperの設定ですべて設定可能です。コードクリーンアップルール(たとえば、用途をvarに置換するかどうかなど)、コードスタイルルール(変数の名前付けなど)、フォーマットルール(例:中かっこの配置方法など)があります。

私は、これらの設定の概要を説明しますと、それらがどのようにコーディング標準を整形すると、自動的にコードのクリーンアップを介して適用することで使用することができます記事を書いた:1日aの終わりに

http://gojisoft.com/blog/2010/05/10/coding-standards-using-resharper/

を彼らの多くは、コーディングスタイルや冗長コードの削除に関心があります。コンパイルされたコードには何の影響もありません。あなたやチームのコーディングスタイルに合わせて、それらの多くを設定することができます。

2

それらの変更のすべてがコンパイルされCILコードには何ら影響を与えないはずです - 彼らは、C#のコード自体の読みやすさにちょうどReSharperのの意見です。

これらのすべての設定は、お客様のニーズに合わせて調整することができます。ほとんどの場合、それは個人的な好みの問題です。

3

これらは必要ありません。

これらは、resharperによって設定されたコーディング標準に従います。素晴らしいことは、あなた自身の方法でコーディング標準を設定できることです。

ReSharperのおよそ美しいものは、しかし、あなたが特定の方法であなたがいつもやった何かをやってのさまざまな方法を学習してしまうということです。

5

これらはすべて本当に必要ですか?

何も必要ありません。

それは本当に私のプログラムの効率に影響を与えるために起こっていますか?

パフォーマンスやセマンティクスを変更するような方法でコンパイルされたコードに影響を与えることはありません。

私はそれがvarキーワードで私のクラス名に置き換えることによって行うことが起こっている良いものを意味します。結局、コンパイル時には、varもクラス名に置き換えられます。

読みやすいコード。

これらのことを行うようにプログラムされているか、実際には何か別の方法で影響を及ぼしているからですか?

はい。あなたが好きではない場合、これらは設定可能です。

1)大丈夫ですか?

SomeObject o = new SomeObject(); 

最初SomeObject冗長と無用ですvarでそれにはあまり読みやすく、間違いなくより読みません。複雑な定義の場合には、

var dictionary = new Dictionary<string, Dictionary<string, List<string>>(); 

などがあります。しかし、これは過度に過ぎる可能性があります。例えば

string s = "s"; 

var i = 5; 

int i = 5; 

上すなわちよう

var s = "s"; 

より好ましいです3210
var i = 2147483648; 

は、タイプがiのものがすぐに分かりませんので、実際には悪いです。非複雑な定義の場合、私は暗黙の型定義よりも明示的な型定義を使用する方が好きです。また、時にはあなたは

IFoo foo = new Foo(); 

が明示的Fooとして、それを入力しfooIFoovar一方を入力して言いたいです。

2)一般的に、コードは少なくなります。

3)私はこの提案が嫌いです。私は先頭のアンダースコアが嫌いです。メンバー変数には通常の命名規則が使用されていますが、わかりやすくするために、それらの前にはthisを付けています。私はこれをオフにするだろう。

public SomeObject(string name) { 
    this.name = name; 
} 

は、私の意見で

public SomeObject(string name) { 
    _name = name; 
} 

よりも読みやすいです。

4)これはどうしてですか?私はこれで少し混乱しています。それは部分的であり、クラス定義の別の部分が継承を持っているからですか?私はそれがセマンティクスを変更する場合にこれをしているとは想像できません。私はこれをオフにするだろう。

5)私は(3を参照)

+0

#4について:ReSharperは、OPのコメントで指摘されているように、部分クラスの別の部分によって基本クラスが宣言されている場合にのみこれを示唆しています。この場合、WPF UserControlのコードビハインドがXAMLのフロントエンドで基底クラスを宣言していることがわかります。 –

+0

@djacobson:ああ、ありがとう。個人的には、基本クラスの冗長なステートメントでより明確になると思います。 – jason

+0

Re#4、私は常に冗長ベースクラスを削除します。後で私のウィンドウをUserControlに変更したい場合、またはUserControlをページに変更したい場合は、XAMLを変更するだけですべてが機能します。冗長な ":UserControl"を保持していれば、両方の場所(XAMLとコードビハインド)を変更する必要があります。ドライ。 –