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

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

それは行きますか：

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

アイテムの順序について厳格な規則があるかどうか知りたいのですが。私はいたるところにいる。どこでもできるように、特定の基準を守りたいです。

本当の問題は、私のより複雑なプロパティがメソッドのように見えて、コンストラクターの前の最上部で場違いに感じられることです。

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

StyleCopルールドキュメントによると、順序は次のとおりです。

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

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

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

• 公衆
• 内部
• 保護された内部
• 保護された
• 民間

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

• 静的
• 非静的

フィールドの静的/非静的グループのそれぞれの中で、読み取り専用、非読み取り専用の順に並べます（SA1214およびSA1215）

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

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

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

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

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

これは古いですが、それでも非常に関連性の高い質問なので、これを追加します。以前に読んだ、または読んだことがないクラスファイルを開いたときに、最初に何を探しますか？田畑？プロパティ？経験から、ほぼ常にコンストラクタを探していることに気づきました。理解すべき最も基本的なことは、このオブジェクトの構築方法だからです。

したがって、私はコンストラクターをクラスファイルの最初に配置し始め、その結果は心理的に非常にポジティブです。他のものの束の後にコンストラクターを置くという標準的な推奨事項は不快に感じます。

C＃6で予定されているプラ​​イマリコンストラクター機能は、コンストラクターの自然な場所がクラスの一番上にあるという証拠を提供します。実際、プライマリコンストラクターは中かっこの前でも指定されます。

このように並べ替えを行うと、どの程度違いが生じるのかはおかしいです。using最初にシステム名前空間を使用して、ステートメントがどのように順序付けされていたかを思い出します。Visual Studioの「Organize Usings」コマンドはこの順序を使用しました。現在using、はアルファベット順に並べられており、System名前空間には特別な扱いはありません。結果は、よりシンプルでクリーンに感じられます。

言語や業界標準については知りませんが、各セクションを#regionで囲んで、この順に並べる傾向があります。

ステートメントの使用

名前空間

クラス

プライベートメンバー

パブリックプロパティ

コンストラクタ

パブリックメソッド

プライベートメソッド

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

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

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

前述のとおり、C＃言語にはレイアウトを指示するものは何もありません。私は個人的にリージョンを使用しており、平均的なクラスに対してはこのようなことをしています。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

とにかく私には理にかなっています

StyleCopから

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

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

通常、私は次のパターンに従うようにしています：

• 静的メンバー（通常、他のコンテキストがあり、スレッドセーフでなければなりません）
• インスタンスメンバー

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

• 演算子（常に静的）
• フィールド（コンストラクタの前に初期化）
• コンストラクタ
• デストラクタ（コンストラクタをフォローする伝統です）
• プロパティ
• メソッド
• イベント

次に、メンバーは可視性で並べ替えられます（表示が少ないものから表示されやすいものへ）。

• 民間
• 内部
• 内部保護
• 保護された
• 公衆

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

私の好みは、種類別に注文し、次のように表示を減らすことです

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に違反していることを知っています。誰かが、インターフェースの前に型の実装の詳細を配置する必要があるという正当な理由を私に与えることができるなら、私は変更したいです。現在、私はプライベートメンバーを最後に置くことを強く望んでいます。

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

あなたが見つける可能性が最も近いのは、Brad Abramsによる「設計ガイドライン、マネージコード、.NET Framework」（http://blogs.msdn.com/brada/articles/361363.aspx）です。

ここでは、多くの標準について概説します。関連するセクションは2.8だと思います。

これについて提案された唯一のコーディングガイドラインは、クラス定義の先頭にフィールドを配置することです。

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

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

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

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

私はそれを可能な限り単純にします（少なくとも私にとっては）

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

確かに、それを強制する言語には何もありません。プロパティ、メソッドなどに関係なく、可視性（パブリック、保護、プライベート）でグループ化し、＃regionsを使用して、関連するものを機能的にグループ化する傾向があります。クライアントが最初に知る必要があるので、構築メソッド（実際のctorでも静的ファクトリー関数でも）は通常、一番上にあります。

これは古いのですが、私の注文は次のとおりです。

パブリック、保護、プライベート、内部、抽象の順に

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

私はまた、このようなプロパティを（略式のアプローチの代わりに）書き出すのが好きです

// 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; }
}