プロジェクトでStyleCopのガイドラインに従って、最終的に結果のコードが優れているかどうかを確認しようとしています。ほとんどのルールは合理的であるか、コーディング標準に関する意見の問題ですが、私を困惑させるルールが1つあります。それは、他の誰もそれを推奨するのを見たことがないため、明確な利点が見られないためです。
SA1101:{メソッドまたはプロパティ名}の呼び出しは、アイテムがクラスのメンバーであることを示すために、「this。」プレフィックスで始まる必要があります。
欠点は、コードの方が明らかにその方法が冗長であるため、そのルールに従うことの利点は何ですか?ここの誰かがそのルールに従っていますか?
コードが一目でわかりやすくなります。 this
を使用すると、次のことがより簡単になります。
私はあなたがそれを必要とするシナリオでない限り、私は本当にこのガイダンスに従いません:
this.name = name;
)またはEquals
(return this.id == other.id;
)それ以外は、この混乱を考慮します。だから私はルールをオフにします。
この記事はそれを少し説明すると思います
http://blogs.msdn.Microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx
... Microsoftの優秀な若い開発者(そうですね、私です)は、自分のチームで使用されているC#スタイルからの差異を検出できる小さなツールを自分で書くことにしました。 StyleCopが誕生しました。今後数年間、マイクロソフト内のさまざまなチームから見つけたC#スタイルのガイドラインをすべてまとめ、これらのスタイルに共通するベストプラクティスをすべて選びました。これらは、StyleCopルールの最初のセットを形成しました。この取り組みから生まれた最も初期の規則の1つは、クラスメンバーを呼び出すためのthisプレフィックスの使用と、アンダースコアプレフィックスの削除です。フィールド名。 C#スタイルは、古いC++部族とは別に正式に成長しました。
this.This
this.Does
this.Not
this.Add
this.Clarity
this.Nor
this.Does
this.This
this.Add
this.Maintainability
this.To
this.Code
"this。"の使用法は、過度に使用したり、強制的なスタイルの要件を使用したりする場合、実際にコードやその内容を理解していない開発者が1%未満であり、それを作成しているという装いの下で使用された仕掛けにすぎません。簡単に読みやすく保守しやすいコードを書きたい99%にとっては苦痛です。
入力を開始するとすぐに、Intellisenceは入力している範囲の「this」で利用可能なコンテンツを一覧表示します。クラスメンバーを公開する必要はありません。コーディングする内容に完全に無知でない限り、必要なアイテムを簡単に見つけることができます。
完全に無知であっても、「これ」を使用してください。何が利用できるかを示唆するために、コードに残さないでください。 Resharperのようなアドオンも多数あり、スコープを明確にし、オブジェクトのコンテンツをより効率的に公開するのに役立ちます。提供されているツールの使用方法を学習してから、多数の同僚から嫌われている悪い習慣を身に付けることをお勧めします。
静的、ローカル、クラス、またはグローバルコンテンツのスコープを本質的に理解していない開発者は、スコープを示すために「ヒント」に頼るべきではありません。 "この。"少なくともハンガリー語の表記は、変数が参照している型についてのアイデアを提供し、いくつかの利点を提供するため、ハンガリー語の表記よりも悪いです。クラスフィールドメンバーを示すために「_」または「m」を使用してから「this」を参照したいどこにでも。
「これ」を使用していないため、コードスコープと繰り返し戦ったり、常にバグのあるコードを書き込んだりする開発者の問題も見たことがありません。明示的に。 「これ」という根拠のない恐怖です。将来のコードのバグを防ぎ、多くの場合、無知が重視される場合に使用される引数です。
プログラマーは、「これ」という経験とともに成長します。自転車に乗る方法を学ぶために最初に使用しなければならなかったので、大人になって自転車に補助輪を乗せるように誰かに頼むようなものです。そして、大人が自転車に乗る回数は1,000回に1回は自転車から落ちる可能性がありますが、トレーニングホイールの使用を強制する理由にはなりません。
"この。" C#の言語定義から禁止する必要があります。残念ながら、これを使用する理由は1つだけです。それは、あいまいさを解決することです。あいまいさを解決することもできます。
コンパイラーは、参照の前にthis
を付けるかどうかを気にしないことに注意してください(ローカル変数とフィールドとの名前の衝突がない場合、または現在のインスタンスで拡張メソッドを呼び出したい場合を除きます)。
それはあなたのスタイル次第です。個人的に削除this.
信号からノイズ比を減少させると思うので、コードから。
Microsoftがこのスタイルを内部で使用しているからといって、必ずしもそうする必要はありません。 StyleCopは公開されたMS内部ツールのようです。私は、次のような公共の事柄に関するMicrosoftの慣習を順守しているすべての人です。
...しかし、コードのプライベートレルムで発生することはプライベートです。チームが同意することは何でもしてください。
一貫性も重要です。特にコードスタイルが期待どおりの場合は、コードを読み取る際の認知的負荷が軽減されます。しかし、外国のコーディングスタイルを扱う場合でも、それが一貫していれば、慣れるまでに時間がかかりません。 ReSharperやStyleCopなどのツールを使用して、重要だと思われる場所で一貫性を確保します。
.NET Reflectorを使用すると、MicrosoftはとにかくBCLのStyleCopコーディング標準を順守するのが得意ではないことを示唆しています。
this
を使用するいくつかの基本的な理由(そして、偶然にも、クラスの値の前に、クラスが属しているクラスの名前を常に付けます。
1)明快さ。この瞬間、クラス定義で宣言した変数と、ローカル、パラメーターなどとして宣言した変数がわかります。 2年後、あなたはそれを知らないでしょう、そしてあなたが親を前もって明確に述べるならば絶対に無意味であり、必要とされない再発見の不思議な航海に行くでしょう。他の誰かがあなたのコードに取り組んでいるのは、最初から考えがわからないので、すぐにメリットがあります。
2)Intellisense。 「これ」と入力するとヘルプでインスタンス固有のすべてのメンバーとプロパティを取得します。特に、他の誰かのコードや、2、3年間見ていないコードを維持している場合は、物事を見つけるのが非常に簡単になります。また、どの変数とメソッドがどこでどのように宣言されているかについての誤解によって引き起こされるエラーを回避するのにも役立ちます。コンパイラーがコードを詰まらせるまで表示されないエラーを発見するのに役立ちます。
3)プレフィックスやその他の手法を使用しても同じ効果が得られることは確かですが、実際にサポートされている言語に組み込まれているメカニズムがあるのに、なぜ問題を処理するメカニズムを発明するのかという疑問が生じます。 IDE?タッチタイプの場合、一部でも、アンダースコアキーに到達するためにホームポジションから指を離さなくても済むため、最終的にはエラー率も減少します。
1文字か2文字入力しないことで節約できる時間を大いに活用している多くの若いプログラマーがいます。ほとんどの時間は、コーディングではなくデバッグに費やされます。タイピングの速度をそれほど気にする必要はありません。あなたがどれだけ速くできるかについてもっと心配してください理解コードで何が起こっているか。合計5分のコーディングを節約し、さらに10分のデバッグに費やして勝利すると、どれだけ速くlookを実行していても、速度が低下します。
静的メンバーとインスタンスメンバーへのアクセスを一目で区別できるので本当に便利だと思うので、私はそれに従います。
そしてもちろん、私はそれを自分のコンストラクターで使用する必要があります。これは、通常、コンストラクターパラメーターに、値が割り当てられるフィールドと同じ名前を付けるためです。したがって、フィールドにアクセスするには「this」が必要です。
さらに、関数内で変数名を重複させることもできるので、 'this'を使用するとより明確になります。
class foo {
private string aString;
public void SetString(string aString){
//this.aString refers to the class field
//aString refers to the method parameter
this.aString = aString;
}
}
私は主にintellisenseの理由でそれに従います。とてもいいタイピングthis.
およびプロパティ、メソッドなどの簡潔なリストを取得します。