StyleCopは、メンバー変数の前にm_. それは c# コーディング スタイルの公式ラインですか? 私はそれがMSからのものだと思います。誰かこれについて何か知っていますか??
デフォルトでは、StyleCop はアンダースコア、m_ などを使用してローカル クラス フィールドをマークすることを許可せず、「this」を優先します。プレフィックス。「これ」を使用する利点。フィールドだけでなく、メソッド、プロパティなどを含むすべての要素タイプに等しく適用されるため、コードを表示するためにどのエディターが使用されているかに関係なく、クラス メンバーへのすべての呼び出しが即座に認識されます。もう 1 つの利点は、インスタンス メンバーと静的メンバーをすばやく認識できるように区別できることです。静的メンバーにはプレフィックスが付けられません。
_私は、プライベート メンバー フィールドの接頭辞を少し付けたいと思っています。対応するゲッター/セッターと大文字と小文字を区別するだけではありません。
Style Cop は、特定の(この場合は Microsoft の内部) コーディングスタイルを適用するためのツールであることに注意してください。その推奨事項は、FxCop の推奨事項や、(優れた) Framework Design Guidelines ブックからのその他の推奨事項と同じ重みを与えられるべきではありません。特定のソース コードを管理する人物または組織は、そのコードのスタイルガイドラインのソースである必要があります。「公式」電子メール署名または「公式」コーディング フォントがあるのと同様に、グローバルな「公式」コーディング スタイルはありません。
それはすべてあなたのスタイルの問題です。そのルールに入って、自分のコーディング スタイルに合うように変更して、煩わしくならないようにすることができます。個人的には、m_ は少し冗長に感じます。「メンバーであることは既に知っています!」アンダースコアの例を使用するだけです。_メンバー。
タイプメンバーの名前のセクションを見ると、次のように書かれています。
フィールド命名ガイドラインは、静的パブリック フィールドと保護フィールドに適用されます。内部フィールドとプライベート フィールドはガイドラインの対象外です
（私の強調）
私は、Stylecop がthis接頭辞を好むことにいつも悩まされてきました。次のように言っているので、クラス メンバーを呼び出していることがすぐにわかります。
Load();
そして書く：
this.Load();
それ以上のことはわかりません。行が冗長になるだけです。確かに、Load静的である可能性がありますが、私は何を気にしますか?
m_個人的にはアプローチが好きです。メンバー変数のコードを簡単に検索できるようになり、すべてのメンバー変数がメンバー ドロップダウンにグループ化され、m_Intellisense に入るとすぐにリストがすべてのメンバー変数に絞り込まれます。thisプレフィックスを使用する場合、これは得られません。
コア C# ライブラリに対して Reflector を実行すると、m_および のような接頭辞が表示_されるため、明らかに、Microsoft はプライベートおよび内部メンバーの命名についてかなり柔軟です。
メンバー変数とメソッドのプレフィックスを含むコードを見るとthis、その開発者に対する私の意見を下げる傾向があります。特に、それについての会話が「Stylecop は私がすべきだと言っている」という理由でそれを正当化することで終わる場合は特にそうです。