web-dev-qa-db-ja.com

クラス内の項目の順序：フィールド、プロパティ、コンストラクタ、メソッド

クラス構造の観点からの項目の順序に関する公式のC＃ガイドラインはありますか？

それは行きますか：

  • パブリックフィールド
  • プライベートフィールド
  • プロパティ
  • コンストラクタ
  • 方法

商品の順番について厳格で速いルールがあるのであれば、私は興味がありますか？私はいたるところに親切です。私はどこでもそれをすることができるように私は特定の標準に固執したいです。

本当の問題は、私のより複雑なプロパティはメソッドによく似ていることになり、コンストラクタの前の先頭に配置がずれていることです。

ヒントや提案はありますか？

c#.netcoding-style
562
mmcdole

StyleCop Rules Documentation によると、順序は次のとおりです。

クラス、構造体、またはインタフェース内：（SA1201およびSA1203）

  • 定数フィールド
  • フィールド
  • コンストラクタ
  • ファイナライザ（デストラクタ）
  • 代議員
  • イベント
  • 列挙型
  • インターフェース（インターフェースの実装）
  • プロパティ
  • インデクサー
  • 方法
  • 構造体
  • クラス

これらの各グループ内で、アクセス順に並べ替えます。（SA1202）

  • パブリック
  • 内部
  • 保護された内部
  • 保護された
  • 非公開

各アクセスグループ内で、静的、次に非静的の順に並べ替えます。（SA1204）

  • 静的
  • 非静的

静的/非静的グループの各フィールド内で、読み取り専用、次に非読み取り専用の順に指定します。（SA1214およびSA1215）

  • 読み取り専用
  • 非読み取り専用

展開されたリストの長さは130行なので、ここでは展開しません。展開されたメソッド部分は次のとおりです。

  • パブリックスタティックメソッド
  • 公開メソッド
  • 内部静的メソッド
  • 内部メソッド
  • 保護された内部静的メソッド
  • 保護された内部メソッド
  • 保護された静的メソッド
  • 保護されたメソッド
  • プライベート静的メソッド
  • プライベートメソッド

ドキュメントには、規定の順序が適切でない場合（複数のインタフェースが実装されている場合、インタフェースのメソッドとプロパティをグループ化する必要がある場合など）、部分クラスを使用して関連メソッドとプロパティをグループ化することがあります。

817
Jonathan Wright

可視性や項目の種類（フィールド、プロパティ、メソッドなど）でグループ化するのではなく、機能でグループ化するのはどうですか。

32
Ryan Lundy

これは古いけれども非常に関連性のある質問なので、私はこれを付け加えます。あなたが以前に読んだことがあるかもしれないし、ないかもしれないクラスファイルを開いたときに最初に探すものは何ですか？フィールド？プロパティ？理解するべき最も基本的なことはこのオブジェクトがどのように構築されるかであるので、私はほとんど常にコンストラクタのために捜しに行くという経験から私は気付いた。

そのため、クラスファイルの先頭にコンストラクタを配置し始めましたが、その結果は心理的に非常にポジティブです。他のものの束の後にコンストラクタを置くことの標準的な勧告は不快に感じます。

C＃6の次期プライマリコンストラクタ機能は、コンストラクタの自然な場所がクラスの最上位にあるという証拠を提供します - 実際、プライマリコンストラクタは開き括弧の前でも指定されています。

このような並べ替えがどれほどの違いをもたらすかは面白いです。それはusingステートメントがどのように順序付けられていたかを思い出させます - 最初にシステム名前空間で。 Visual Studioの "Organize Usings"コマンドはこの順序を使用しました。今ではusingsはアルファベット順に並んでいるだけで、Systemの名前空間には特別な扱いはありません。結果は単によりシンプルでクリーンに感じます。

18
bright

私は IDesign または Brad AbramのWebサイト にリストされているものからのコーディング標準の使用をお勧めします。それらは私が見つけた最高の2つです。

ブラッドは言うだろう...

クラスメンバーはアルファベット順に並べられ、セクション（フィールド、コンストラクタ、プロパティ、イベント、メソッド、プライベートインタフェースの実装、入れ子型）にグループ化されるべきです。

14
Elijah Manor

言語や業界標準についてはわかりませんが、各セクションを＃領域で囲んで、この順序で説明するのが一般的です。

ステートメントを使う

名前空間

クラス

非公開メンバー

パブリックプロパティ

コンストラクタ

パブリックメソッド

プライベートメソッド

13
Wayne

前述したように、C＃言語にはレイアウトを指示するものは何もありません。私は個人的に地域を使用しています。そして、平均的なクラスのためにこのようなことをします。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

とにかく私には意味があります

5
Mitchel Sellers

通常私は次のパターンに従うことを試みます：

  • 静的メンバー（通常は他のコンテキストを持ち、スレッドセーフでなければならない、など）
  • インスタンスメンバー

各部分（静的およびインスタンス）は、以下のメンバータイプから構成されています。

  • 演算子（常に静的です）
  • フィールド（コンストラクタの前に初期化されます）
  • コンストラクタ
  • デストラクタ（はコンストラクタに従う伝統です。
  • プロパティ
  • 方法
  • イベント

それから、メンバーは可視性によってソートされます（小さいものから大きいものへ）。

  • 非公開
  • 内部
  • 内部保護
  • 保護された
  • パブリック

順序は定説ではありません。単純なクラスは読みやすくなりますが、より複雑なクラスではコンテキスト固有のグループ化が必要になります。

4
Michael Damatov

StyleCopから

プライベートフィールド、パブリックフィールド、コンストラクタ、プロパティ、パブリックメソッド、プライベートメソッド

StyleCopはMSのビルドプロセスの一部なので、事実上の標準と見なすことができます。

4
blowdart

私の好みは種類順に並べてから、次のように視認性を下げることです

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

私はこれがStyle Copに違反していることを知っています、そして誰かが私が変更しても構わないと思っているそのインターフェースの前にタイプの実装詳細を置くべきである正当な理由を与えることができるなら。現在のところ、私は個人会員を最後にすることを強く望んでいます。

注：パブリックフィールドまたは保護フィールドは使用しません。

3
Aluan Haddad

最も近いと思われるのは、「デザインガイドライン、マネージコード、.NET Framework」（ http://blogs.msdn.com/brada/articles/361363.aspx ）by Brad Abrams

多くの標準がここに概説されています。関連するセクションは2.8です。

3
Rory Becker

私は、プライベートフィールドをコンストラクタと一緒に一番上に配置し、その後パブリックインターフェイスビットを配置し、次にプライベートインターフェイスビットを配置することを好みます。

また、あなたのクラス定義が項目の順序付けが問題になるほど長い場合、それはおそらく コード臭い で、クラスがかさばっていて複雑すぎることを示しています。あなたはリファクタリングするべきです。

2
Wedge

私はそれをできるだけ単純にしておく（少なくとも私にとっては）

列挙型
宣言
コンストラクタ
オーバーライド
メソッド
プロパティ
イベントハンドラ

2
Pat

私がこれについて提案した見た唯一のコーディングガイドラインはクラス定義の一番上にフィールドを置くことです。

次にコンストラクタを置く傾向があります。

私の一般的なコメントは、ファイルごとに1つのクラスに固執する必要があるということです。また、クラスが十分に大きいためにプロパティ対メソッドの編成が大きな問題になる場合それは複数の懸念を表していますか？

2
Hamish Smith

その言語には、それを何らかの形で強制するものは何もありません。私は物事を可視性（パブリック、次に保護され、プライベート）でグループ化し、#regionsを使用して関連するものを機能的にグループ化する傾向があります。構築方法（実際のctorsかstatic factory関数かにかかわらず）は、クライアントが知る必要がある最初のものであるため、通常は一番上にあります。

1
Jeff Kotula

私はこれが古いことを知っていますが、私の注文は以下の通りです：

公開、保護、プライベート、内部、要約の順に

  • 定数
  • 静的変数
  • フィールド
  • イベント
  • コンストラクタ
  • 方法
  • プロパティ
  • 代議員

私はこのようなプロパティを書き出すのも好きです（速記の代わりに）

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}
1
user6630825