name - c# クラス の プロパティ




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

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

それは行く:

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

私はアイテムの順序について厳しいと速いルールがある場合は興味がありますか? 私はどこにいてもまあまあです。 私はどこにでもできるので、特定の基準に固執したい。

実際の問題は、私のより複雑なプロパティがメソッドのように多く見えることになり、コンストラクタの前で一番上の位置が違うということです。

任意のヒント/提案?


StyleCopから

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

StyleCopはMSビルドプロセスの一部なので、デファクトスタンダードとして見ることができます


StyleCop Rules Documentationによると、注文は以下の通りです。

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

  • 定数フィールド
  • フィールド
  • コンストラクタ
  • ファイナライザ(デストラクタ)
  • 代表者
  • イベント
  • 列挙型
  • インターフェイス
  • プロパティ
  • インデクサー
  • メソッド
  • 構造
  • クラス

これらのグループのそれぞれ内で、アクセス順に並べ替えられます(SA1202)

  • パブリック
  • 内部
  • 保護された内部
  • 保護された
  • プライベート

各アクセス・グループ内で、静的で順序付けし、次に静的で順序付けします。(SA1204)

  • 静的
  • 非静的

各静的/非静的フィールドのグループ内では、読み取り専用で順序付けし、非読み取り専用で順序付ける(SA1214およびSA1215)

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

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

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

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


これは古いですがまだまだ関連性の高い質問ですので、これを追加します:あなたが読んだことがあるかもしれないクラスファイルを開いたときに最初に探すのは何ですか? フィールド? プロパティ? ほとんどの基本的なことは、このオブジェクトがどのように構築されているかということなので、私はコンストラクターのためにほとんどいつも狩りをしていることが経験から分かっています。

したがって、私はクラスファイルに最初にコンストラクタを入れ始めました。その結果は心理的に非常に肯定的でした。 他のものの束の後にコンストラクタを置くという標準的な勧告は、不協和音を感じる。

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

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


プライベートフィールドをコンストラクタと一緒に一番上に置いて、その後にパブリックインターフェイスビットを置いてからプライベートインターフェイスビットを置くことを好みます。

また、クラスの定義が項目の順序付けに十分長いとすれば、それはおそらくクラスが大きすぎて複雑であることを示すコードの匂いであり、リファクタリングする必要があります。


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


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


私の好みは、種類別に注文してから、次のように視認性を減らすことです

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に違反していることを知っています。もし誰かが私のインタフェースの前にタイプの実装の詳細を置くべき理由を誰かに教えてもらえれば幸いです。 現在、プライベートメンバーを最後に置くことに対する強い好みがあります。

注:私は公共または保護されたフィールドを使用しません。


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

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

クラスメンバはアルファベットで区切られ、セクション(フィールド、コンストラクタ、プロパティ、イベント、メソッド、プライベートインターフェイスの実装、ネストされた型)


私はできるだけシンプルにしておく(私にとっては少なくとも)

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


私は言語や業界の標準についてはわかりませんが、私は各セクションを#regionで囲んでこの順番に物事を置く傾向があります:

ステートメントの使用

名前空間

クラス

プライベートメンバー

パブリックプロパティ

コンストラクタ

パブリックメソッド

プライベートメソッド







coding-style