737

クラス構造に関する項目の順序に関する公式の C# ガイドラインはありますか?

うまくいきますか：

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

アイテムの順序について厳格なルールがあるかどうか気になりますか? 私はどこにでもいるようなものです。どこでもできるように、特定の基準に固執したい.

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

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

4

16 に答える 16

1149

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

クラス、構造体、またはインターフェイス内: (SA1201 および SA1203)

  • 定数フィールド
  • 田畑
  • コンストラクター
  • ファイナライザー (デストラクタ)
  • デリゲート
  • イベント
  • 列挙型
  • インターフェイス (インターフェイスの実装)
  • プロパティ
  • インデクサー
  • メソッド
  • 構造体
  • クラス

これらの各グループ内で、アクセス順: (SA1202)

  • 公衆
  • 内部
  • 保護された内部
  • 保護された
  • プライベート

各アクセス グループ内で、静的順、次に非静的順: (SA1204)

  • 静的
  • 非静的

各フィールドの静的/非静的グループ内で、読み取り専用、次に非読み取り専用の順に並べます: (SA1214 および SA1215)

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

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

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

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

于 2008-11-22T06:41:49.557 に答える
42

可視性や項目の種類 (フィールド、プロパティ、メソッドなど) ごとにグループ化するのではなく、機能ごとにグループ化するのはどうですか?

于 2008-09-29T20:30:43.913 に答える
20

言語や業界標準についてはわかりませんが、各セクションを #region でラップして、次の順序で並べる傾向があります。

ステートメントの使用

名前空間

クラス

プライベートメンバー

パブリック プロパティ

コンストラクター

公開メソッド

プライベート メソッド

于 2008-09-29T20:30:02.417 に答える
15

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

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

クラス メンバーはアルファベット順に並べ、セクション (フィールド、コンストラクター、プロパティ、イベント、メソッド、プライベート インターフェイスの実装、ネストされた型) にグループ化する必要があります。

于 2008-09-29T20:30:20.777 に答える
7

通常、私は次のパターンに従おうとします。

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

各パーツ (静的およびインスタンス) は、次のメンバー タイプで構成されます。

  • 演算子 (常に静的)
  • フィールド (コンストラクターの前に初期化)
  • コンストラクタ
  • デストラクタ (コンストラクタに従うのが伝統です)
  • プロパティ
  • メソッド
  • イベント

次に、メンバーは可視性によって並べ替えられます (可視性の低いものから多いものへ)。

  • プライベート
  • 内部
  • 内部保護
  • 保護された
  • 公衆

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

于 2008-09-29T20:40:13.937 に答える
6

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

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 に違反していることを知っており、型の実装の詳細をそのインターフェイスの前に配置する必要がある正当な理由を誰かが教えてくれれば、私は喜んで変更します。現時点では、プライベート メンバーを最後に配置することを強く好みます。

注: public または protected フィールドは使用しません。

于 2016-12-18T14:00:03.123 に答える
6

前述のように、C# 言語にはレイアウトを決定するものは何もありません。私は個人的に領域を使用しており、平均的なクラスに対してこのようなことを行っています。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

とにかく理にかなっている

于 2008-09-29T20:31:18.310 に答える
5

StyleCopから

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

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

于 2008-09-29T20:30:53.490 に答える
3

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

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

于 2008-09-29T20:36:05.927 に答える
3

できるだけシンプルにしています（少なくとも私にとっては）

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

于 2008-09-29T20:42:22.153 に答える
3

最も近いものは、Brad Abrams による「Design Guidelines, Managed Code and the .NET Framework」( http://blogs.msdn.com/brada/articles/361363.aspx ) です。

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

于 2008-09-29T20:29:33.620 に答える
3

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

public、protected、private、internal、abstract の順に

  • 定数
  • 静的変数
  • 田畑
  • イベント
  • コンストラクター
  • メソッド
  • プロパティ
  • デリゲート

私はまた、このようなプロパティを書き出すのが好きです (省略形のアプローチではなく)

// 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; }
}
于 2017-12-07T07:08:16.247 に答える
2

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

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

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

于 2008-09-29T20:29:28.253 に答える
1

何らかの方法でそれを強制する言語には確かに何もありません。私は可視性 (public、protected、private) によって物事をグループ化し、#regions を使用して、プロパティ、メソッドなどに関係なく、関連するものを機能的にグループ化する傾向があります。構築メソッド (実際の ctor であれ静的ファクトリ関数であれ) は、クライアントが最初に知る必要があるものであるため、通常は一番上にあります。

于 2008-09-29T20:26:38.790 に答える