web-dev-qa-db-ja.com

メンバー変数のC＃命名規則について

_private/public_メンバー変数に名前を付けないように、最初の文字の場合のみ異なるという方法でSO）のどこかでアドバイスを見ました。

_private string logFileName;

public string LogFileName
{
    get
    {
        return logFilename
    ....
_

および：_private System.Windows.Forms.MainMenu mainMenu;_

および：DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();

そして：

_public Version Version
{
    get;
    set;
}
_

そして：

_    private void CheckPollingType(PollingType pollingType)
    {
_

だから、私は間違って聞いたのですか？これらの命名規則に何か問題はありますか？はいの場合、それを行うより良い方法は何ですか？リンク、参照はプラスです。

ありがとう。

c#naming-conventions
38
Hamish Grubijan

それは間違いなく非常に人気のある命名規則であり、なぜあなたはそれに反対するべきかわかりません。

MSDNが提供するC＃の命名規則 および MSDNが提供する一般的な命名規則 に従うことをお勧めします。

具体的には、プロパティについて次のように述べています。

名詞、名詞句、または形容詞を使用してプロパティに名前を付けます。

プロパティにはデータが保持されるため、名詞句や形容詞はプロパティに適しています。

Getメソッドの名前と一致するプロパティを使用しないでください。

たとえば、プロパティにEmployeeRecordという名前を付けたり、メソッドGetEmployeeRecordに名前を付けたりしないでください。開発者は、プログラミングタスクを実行するためにどのメンバーを使用するかを知りません。

ブール型のプロパティには、肯定的なフレーズ（CantSeekではなくCanSeek）を付けてください。オプションで、ブール型プロパティの先頭にIs、Can、またはHasを付けることもできますが、値を追加する場所のみです。

プロパティにそのタイプと同じ名前を付けることを検討してください。

列挙に厳密に型指定されたプロパティがある場合、プロパティの名前は列挙の名前と同じにすることができます。たとえば、CacheLevelという名前の列挙体がある場合、その値の1つを返すプロパティはCacheLevelという名前にすることもできます。

あなたが提案していることに反対する説得力のある理由があれば、彼らはそれを彼らのガイドラインで言及していると思います。

32
Brian R. Bondy

ほとんどの時間クラスレベルの変数には、アンダースコアが付加されます。したがって、myVariableは実際には_myVariableです。多くの人は、ミスを犯しやすいため、1文字で名前を変更することを好みません。

MyVariableとMyVariableを実行するだけで問題はありません。これは単なる慣習であり、誰もがそれに従えば、おそらくうまくいくでしょう。

個人的には、可能な限りプライベート変数を使用せず、プロパティでゲッターとセッターを使用します。ほとんどの場合（常にではありません）、プライベート変数へのアクセスは、プロパティへの書き込みアクセスを許可しないために使用されていました。
これは次の方法で解決できます。

public String MyVariable
{
   get;
   private set;
}
19
kemiller2002

通常、先頭に_が付いたプライベートメンバーが常に表示されます。 （自動プロパティではないと仮定）

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

もちろん、最終的な評決はあなたのチームの慣習です（孤独なオオカミのプロジェクトをしていないか、まったくのバカに取り組んでいないと仮定して）

12
Andy_Vulhop

私はいつも使っているものでリングに帽子を投げます

class ClassName //Classes are PascalCase
{
    public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
    {
       _myProperty = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
    {
        int sampleVar; //local variables are camelCase
    }
    public int MyProperty { get { return _myProperty; } } // Properties are PascalCase

    private int _myProperty; // Private fields are camelCase and start with a _
8
Scott Chamberlain

Microsoftの決定的なガイドラインです

。NETフレームワーク全体で使用される命名規則とスタイル規則の背後にある詳細と理由に興味がある場合は、この本もお勧めします。

楽しい！

3
Doug

いいえ、これらの命名規則に問題はありません。

プロパティバージョンは、実際には.Netフレームワークの設計ガイドラインに従って推奨される形式です。

同様に、フィールド宣言はcamelCasedであるため、フレームワークのガイドラインに準拠しています。変数の前に_またはm_を付ける必要があるかどうかについては、時として宗教的な戦争になります。ただし、それはグループ内で解決する必要がある質問です。

型メンバーの.Netフレームワーク設計ガイドライン

2
JaredPar

パブリックメンバーとプライベートメンバーを区別するためにケースを使用しないと思う理由の1つは、Visual Studio Intellisenseが両方のメンバーを並べて並べるため、気付かずに間違ったメンバーを使用する可能性があるためです。

そうは言っても、コードで（アクセシビリティを区別するために大文字小文字を使用して）説明した規則を使用しますが、問題はありません。

2
Kevin Kibler

C＃のみを実行している場合は問題ありませんが、あなた（またはあなたのチーム/会社）もVB.Net（大文字と小文字を区別しない）を実行している場合は、C＃でこれを実行しない方がよいでしょう。異なる言語間での命名規則があまり違わないようにするためです。

1
Hans Olsson

私が目にする2つの最も一般的な規則は、プライベートメンバー変数の前に_またはm_を付けることです。個人的にはm_規則を好みますが、プロジェクト/チーム全体で一貫している限り、私は本当に気にしません。私は「宗教戦争」に入る人ではありません:)

1
jvandevelde

どの命名規則を選択しても、一貫性を保ってください。それから、少なくとも6か月後にコードに戻ったとき、または新しい人が初めてそれを見るとき、彼らは何が何であるかを理解することができます。

1
ChrisF

ただし、このシナリオには注意してください。

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

Visual Studioはこの状況について警告しますが、違法ではなく、時々すり抜けることがあります。

1
Matt Greer

大文字と小文字が異なる同じ名前の主な問題は、.netのすべての言語で大文字と小文字が区別されるわけではないことです。

それが本当の問題である唯一のシナリオは、ケースによってのみ異なるパブリックメンバーを公開する場合です。設定できる互換性属性があるので、そのようなシナリオのいずれかがある場合はコンパイラーが通知します。

上記で述べたように、これは実際にバッキングプライベートメンバーのシナリオには影響しません。

1
eglasius

提案されている命名規則の基本的な問題は、Intellisenseがプロパティに対してプライベート変数を使用することです。多くの場合、これは実際には問題ではありません（実際、通常は良いことです）が、問題がある場合は、2つの名前を分ける規則が便利です。プライベートメンバー変数にはm_が、プライベートスタティック変数にはc_が好きです。

1
Mike Burton

これは、トピックに関する最上位の検索結果の中でポップアップ表示されるので、私も提案を共有したいと思いました。

パブリック/プライベートメンバーのPascal/camelCase規則に加えて、私は常に2語以上で構成されるメンバー変数名、および単一小文字のワードで構成されるローカル変数名を選択しますまたは単なる文字。

public class MyCanvas : Canvas {
    public int CanvasId { get; private set; }
    private double canvasHeight; // member vars consist of 2+ words
    private double canvasWidth;

    public MyCanvas(int id) {
        CanvasId = id;
        double height = ...; // local vars consist of one Word/letter
        canvasHeight = height;
    }
}

これにより、_のような「おかしい」プレフィックスなしで、一貫性のある意味のある変数名を選択できますが、ローカル変数とメンバー変数を区別することもできます。

1
yacc