web-dev-qa-db-ja.com

C＃フィールド命名ガイドライン？

私は自分で少しのC＃コードに取り組んでいますが、他の開発者を連れてきたり、コードをリリースしたり、コードを販売したりする場合に、最も広く受け入れられている命名規則に従っていることを確認したいと思います。現在、Microsoftが最も広く受け入れられているように設定している命名規則に従っています。彼らが言及していないことの1つは、プライベートフィールドの命名です。ほとんどの場合、保護フィールドのようなcamelCaseで名前が付けられていますが、パラメータ名はcamelCaseである必要があるため、問題が発生します。例として、次のコンストラクターを取り上げます。

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

プライベートフィールドにもcamelCaseを使用すると、クラスフィールドにアクセスするために「this」を使用しない限り、名前の競合が発生します（ほとんどの標準に反することは言うまでもなく、入力が増えることを意味します）。 1つの解決策は、パラメーターに異なる名前を付けることですが、同じデータに2つの異なる名前を付けることは論理的に意味がありません。私が知っている他の唯一の解決策は、C++コーディングでは一般的でしたが、最初にプライベートメンバーにアンダースコアを付けることです（_camelCase）。そのソリューションは、C＃コーディングで一般的に受け入れられていますか？この問題に別の解決策がありますか（クラス自体でも、フィールドにアクセスするためにプロパティのみを使用する（PascalCaseを使用するなど））？

c#naming-conventions
40
ryanzec

Microsoft Naming Guidelines に従ってください。 フィールドの使用に関するガイドライン は、キャメルケースであり、プレフィックスを付けないことを示します。一般的なルールには接頭辞がないことに注意してください。具体的なルールは、静的フィールドと非静的フィールドを区別するためにプレフィックスを付けないことです。

フィールド名または静的フィールド名にプレフィックスを適用しないでください。特に、静的フィールドと非静的フィールドを区別するために、フィールド名にプレフィックスを適用しないでください。たとえば、g_またはs_プレフィックスの適用は正しくありません。

および（from 一般的な命名規則 ）

アンダースコア、ハイフン、またはその他の英数字以外の文字は使用しないでください。

[〜＃〜] edit [〜＃〜]：ドキュメントはprivateに関して特定のものではないことに注意してくださいフィールドですが、protectedフィールドはcamelCaseのみであることを示します。このことから、プライベートフィールドの規則はすべて受け入れられると推測できると思います。確かに、パブリックな静的フィールドは保護されたフィールドとは異なります（大文字です）。私の個人的な意見では、保護/プライベートのスコープは、命名規則の違いを保証するのに十分なほど異なっていません。つまり、保護フィールドのガイドラインに従う場合、パラメーターと区別するために、この点でプライベートフィールドとは異なる扱いをする必要があります。 区別を明確にするために、クラス内のクラスメンバーを参照するときにthisを使用します。

EDIT 2

現在の仕事で使用されている規則を採用しました。これは、プライベートインスタンス変数の前にアンダースコアを付け、一般にPascalCaseを使用してプロパティとして保護されたインスタンス変数のみを公開します。それは私の個人的な好みではありませんでしたが、私が慣れてきたものであり、おそらくより良いものが出てくるまで続くでしょう。

36
tvanfosson

フィールドの__camelCase_は私が見たものから一般的です（私たちの場所で使用しているものであり、Microsoft 。NET Frameworkを優先します ） 。

この標準を使用する私の個人的な理由は、___よりも_this._と入力してプライベートフィールドを識別する方が簡単だということです

例えば：

_void Foo(String a, String b)
{
    _a = a;
    _b = b;
}
_

Versus

_void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}
_

最初の方がはるかに簡単に入力でき、_this.a_の代わりにaというパラメーターに誤って割り当てることを防ぎます。これは、 コード分析 により強化されています：

  • CA1500 変数名はフィールド名と一致してはなりません。

私の他の理由は、ローカル変数またはパラメーター名と衝突しない場合、_this._はオプションであるため（リシャーパーはそれらを削除するようプロンプトを表示します）、どの変数を使用しているかをより難しく認識します。すべてのプライベートフィールドの先頭に___がある場合、どのフィールドがローカルスコープであるかが常にわかります。

51
DaveShaw

一般に、フィールドに名前を付けるために広く使用されている2つの方法があります（常にcamelCaseを使用）：

アンダースコアプレフィックスを使用

void F(String someValue) {
  _someValue = someValue;
}

this.を使用してフィールドにアクセスし、名前の競合を回避する

void F(String someValue) {
  this.someValue = someValue;
}

個人的には後者のほうが好きですが、私が働いている組織によって定められている慣習を使用します。

20
Martin Liversage

私たちの店では、Microsoftが推奨するプライベートメンバー向けのガイドラインを使用して、最初のC＃プロジェクトを開始しました。

camelCaseFieldName

しかし、私たちはすぐにプライベートメンバーとパラメーターの間で混乱に陥り、

_camelCaseFieldName

それは私たちにとってはるかにうまく機能しています。

プライベートメンバーは通常、メソッド呼び出しの外で持続する状態を持ちます-先頭のアンダースコアはそのことを思い出させる傾向があります。

また、プロパティにAutoVariable構文を使用すると、プライベートバッキングフィールドの必要性を最小限に抑えることができます。

public int PascalCaseFieldName { get; set;}

（ほとんど）MSガイドラインに従うニースの簡潔な一連の標準については、 net-naming-conventions-and-programming-standards --- best-practices をチェックしてください。

10
Tom Bushell

短い答え：_privateFieldを使用します。つまり、プライベートフィールドに先頭のアンダースコアを使用します。

長答：ここに行く...

ずっと前に、MicrosoftはcamelCaseをフィールドに使用することを提案していました。 here を参照してください。そのドキュメントが作成された日時、2008年10月22日に注意してください。かなり古い。

ただし、Microsoftの最近のコードベースは、異なる状況を描写しています。

  1. .NET CoreFX githubリポジトリの C＃コーディングスタイル をご覧ください。 ＃3は議論中のポイントです。ここに関連部分があります

    内部フィールドとプライベートフィールドには_camelCaseを使用し、可能な場合はreadonlyを使用します。

  2. また、 Roslynリポジトリのコーディングスタイル を見てください。具体的には、.NET CoreFXの規則に従っていることを示しています。
  3. 。NET標準提供ページ をもう一度見てください。これは、（少なくとも今のところ）.NET CoreFXと同じガイドに従うことも示しています。
  4. CoreCLR は、CoreFXと同じガイドに従うことも推奨します。
  5. Winforms repo でさえ、この同じ標準の使用について話します。
  6. 私は十分に言ったと思う。結論として、Microsoftが提案するガイドに従う場合、何をすべきか知っていると思います。 _privateFieldのようなプライベートフィールドには先頭の下線を使用します。

私の意見：私も個人的にはアンダースコアを先導することを好みます-thisを必要とせずに非常に簡単に区別できます。

4
Sнаđошƒаӽ

StyleCop を使用して、コード全体で一貫性を強制します。 StyleCopは Microsoft内で使用 C＃ソースコードのレイアウト、可読性、保守性、およびドキュメント化のためのベストプラクティスの共通セットを実施します。

ビルド時にStyleCopを実行し、スタイル違反の警告を生成することができます。

特定の質問に答えるには、プライベートフィールドをcamelCaseに入れ、接頭辞に「this」を付ける必要があります。

3
John Myczek

前述のように、 Microsoft Naming Guidelines dosenotはプライベートフィールドとローカル変数の命名をカバーしています。そして、Microsoft自体には一貫性がありません。 Visual Studioでクラスまたは使い捨てパターンを生成すると、次のようなものが作成されます。

public MyClass(int value)
{
    this.value = value;
}

または

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

幸いなことに、Microsoftによってますます多くのコードが開かれたので、リポジトリを見てみましょう。 ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

または 。NET Core

private T[] _array;

あなたは、それは実際にはMicrosoftではなく、.NET Foundationだと言うかもしれません。結構です、 Microsoftリポジトリ を見てみましょう。

private readonly MetricSeries zeroDimSeries;

しかし、これは MVCの古代Microsoft実装 です

private IActionInvoker _actionInvoker;

そのため、プライベートフィールドの命名に関する一般的な慣行や公式のガイドラインはありません。好みの1つを選択して、それに固執するだけです。

3
Kosta_Arnorsky

Philips Healthcare C＃Coding Standard

MSDN-エリック・ガンナーソン

編集：「this」キーワードを使用して、C＃およびJavaの非静的メンバーにアクセスします。

3
Deniz Acay

最も重要なことは、1つの標準を選択してそれに従うことです。 IDesign （右側のリンク）でiDesignのC＃コーディング標準を確認してください。それは命名ガイドラインのようなものをカバーする素晴らしいドキュメントです。ローカル変数とメソッド引数の両方にキャメルケースを使用することをお勧めします。

3
TLiebe

Microsoftの命名規則に従って、プライベートフィールドの前にアンダースコアを付ける必要があります。

例えば：

private int _myValue;

幸運を！

1
Ian P

プライベートクラス変数とメソッドパラメーターを区別するために使用する規則は次のとおりです。

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}
1
Dougc

ReSharperをご覧ください。それはあなたの名前が通常のガイドラインを確認しないすべての場所に下線を引くでしょう、そしてあなたはそれをカスタマイズすることができます。さらに、もちろん、他の生産性向上の負荷と負荷があります。

0
Carlos

私はこれをします; MSDNとほぼ一致しています。

class MyClass : MyBaseClass, IMyInterface
{
    public event EventHandler MyEvent;
    int m_MyField = 1;
    int MyProperty {
        get {
            return m_MyField;
        }
        set {
            m_MyField = value;
        }
    }

    void MyMethod(int myParameter) {
        int _MyLocalVaraible = myParameter;
        MyProperty = _MyLocalVaraible;
        MyEvent(this, EventArgs.Empty);
    }
}

詳細は次のとおりです。 http://jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html

0
Jerry Nixon - MSFT

私はC＃よりもVB=ではるかに多くのことをしたので、前者から後者にいくつかのプラクティス（偏見？）を引き継いでいると思います。

プロパティのプライベートフィールドにアンダースコアを付けるのが好きです-特に大文字と小文字を区別するためにC＃で（その考えはthatとにかく？）そして、モジュール/クラス全体の変数の前に "mスコープを強化することもできます。

気に入らない場合は、本当にこのようなことはしません。通常、タイププレフィックスも使用します（プロパティフィールドを除く）-オブジェクトには「o」、文字列には「s」、整数などの「i」.

査読済みの論文などでこれを実際に防御することはできませんが、それは私たちにとっては有効であり、ケーシングやフィールド/パラメーターの混乱につまずかないことを意味します。

そう ...

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class
0
SteveCinq