VB.NET プライベート フィールドの命名規則

StackOverflow https://stackoverflow.com/questions/7642

  •  08-06-2019
  •  | 
  •  

質問

VB.NET のプライベート フィールドに名前を付けるための公式の規則はありますか?たとえば、「Foo」というプロパティがある場合、通常はプライベート フィールドを「_Foo」と呼びます。これは世間では嫌われているようです 公式ガイドライン:

「フィールド名にプレフィックスを使用しないでください。たとえば、静的フィールドと非静的フィールドを区別するために g_ や s_ を使用しないでください。」

C# では、プライベート フィールドを「foo」、プロパティを「Foo」と呼び、コンストラクター内でプライベート フィールドを「this.foo」として参照できます。VB.NET は大文字と小文字を区別しないため、これを行うことはできません。何か提案はありますか?

役に立ちましたか？

解決

VB ではプライベート フィールドに _ プレフィックスを引き続き使用しているため、プライベート フィールドとして _foo を、プロパティとして Foo を使用します。私はこれを C# や私が書くほぼすべてのコードに対して行います。一般に、私は「正しい」方法というものは実際には存在しないので (非常に悪い方法もいくつかありますが)、「何が正しい方法であるか」ということにあまり囚われず、むしろ一貫してそれを行うことに関心を持っています。

結局のところ、一貫性を保つことで、一連の「正しい」規則を使用するよりもコードがはるかに読みやすく、保守しやすくなります。

他のヒント

これは個人的な好みですが、 いくつかの 区別。C# でも、広く使用されている規則は 1 つもないと思います。

ジェフ・プロサイス 言う

個人的な好みの問題として、私は通常、プライベート フィールドの前に [C# で] アンダースコアを付けます...この規則は .NET Framework で頻繁に使用されますが、全体では使用されません。

から 。NET Framework 設計ガイドライン 第2版​​73ページ。

ジェフリー・リヒター 言う

すべてのフィールドをプライベートにし、インスタンス フィールドの先頭に「m_」を付け、静的フィールドの先頭に「s_」を付けます（C# の場合）

から 。NET Framework 設計ガイドライン 第2版​​47ページ。アンソニー・ムーア（BCLチーム）「m_」と「s_」の使用も検討する価値があると考えています（48 ページ）。

公式ガイドラインは、まさに「ガイドライン」です。いつでもそれらの周りを回ることができます。そうは言っても、通常はフィールドの前にアンダースコアを付けます。 両方 C# と VB.NET。この規則は非常に一般的です (そして明らかに、公式ガイドラインは無視されています)。

プライベート フィールドは、「me」キーワードなしで参照できます (「this」キーワードは C# 用です:)

リンクした設計ガイドラインには、静的なパブリック フィールドと保護されたフィールドにのみ適用されることが明確に記載されています。設計ガイドラインは主にパブリック API の設計に焦点を当てています。プライベートメンバーをどうするかはあなた次第です。私は肯定的ではありませんが、コンパイラが CLS 準拠をチェックする際にプライベート メンバーは考慮されないと比較的確信しています。なぜなら、パブリック/プロテクト メンバーだけがそこに関与するからです (アイデアとしては、「 「_ 文字によるライブラリの使用は許可されていませんか?」 メンバーがプライベートの場合、答えは「何もありません。ユーザーはこれらのメンバーを使用する必要はありません。」ですが、メンバーがパブリックの場合は問題になります。 ）

そうは言っても、私はエコーチェンバーに追加して、何をするにしても一貫性を保つことが重要であることを指摘したいと思います。私の雇用主は、C# と VB の両方のプライベート フィールドに接頭辞 _ を付けることを義務付けています。私たち全員がこの規則に従っているため、他の人が書いたコードを簡単に使用できます。

VB.NET 4.0 では、次のようにプロパティ宣言のゲッターとセッターを明示的に記述する必要がないことをほとんどの人が知っているでしょう。

Public Property Foo As String
Public Property Foo2 As String

VB は、_Foo および _Foo2 というプライベート メンバー変数を自動的に作成します。Microsoft と VS チームは _ 規則を採用しているようですので、これに問題はないと思います。

公式の命名規則はないと思いますが、Microsoft が Microsoft.VisualBasic dll で (リフレクター経由で) m_ を使用しているのを見たことがあります。

私はまだプライベートフィールドにVBの_プレフィックスを使用しているので、私はプライベートフィールドとして_FOOを持ち、財産としてfooを使用します。私はこれをC＃と書いたほぼすべてのコードに対しても行います。一般的に、「正しい」方法は実際には「正しい」方法ではないので（非常に悪い方法がある）、一貫してそれをすることに関心があるので、「それをするのに正しい方法」にあまり巻き込まれません。

明確さと一貫性を実現するために「_」よりも優れたものは見つかりませんでした。短所は次のとおりです。

私はエディターでこれらの行をオフにすることでこの行を回避し、CLS 準拠についてはあまり考えないようにしています。

私も @lomaxx に同意します。チーム全体で一貫性を保つことの方が重要です。 右 大会。

それでも、コーディング規約のアイデアやガイダンスを得るのに適した場所がいくつかあります。

  1. Microsoft Visual Basic および Visual C# の実践的なガイドラインとベスト プラクティス Francesco Balena の『Developers』は、これらの問題の多くに対処する素晴らしい本です。
  2. IDesign コーディング標準 (C# および WCF の場合)
  3. .NETフレームワーク ソースコード (VS2008の場合)

私はプライベートフィールドにはアンダースコア接頭辞を使用することを好みます。メソッドのパラメータには最初の文字を小文字にします。私は、メソッドのパラメータを小文字のキャメルケースにするというガイドラインに従います。これは、クラスの API の一部であるため、プライベート フィールドの名前付けよりも重要であると考えています。。例えば

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

このパターンを使用すると、C# または VB.NET のプライベート フィールドおよびコンストラクター パラメーターとの名前の競合は発生しません。

最も重要なのは、どのスタイルを使用するかではなく、一貫性があることであることに同意します。

そうは言っても、プライベート フィールドの新しい MS/.NET スタイルは _fooVar (アンダースコアの後にキャメルケースの名前が続く) になる傾向があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top