プロジェクト内にC＃および/またはC++構造体を配置するための規則が何であるかを理解しようとしています。それ自身のソースファイルに？はいの場合、私が従う習慣を持たなければならない慣習はありますか？
初年度は、規則について実際には議論されていませんでしたが、一般的に、構造体が使用されている場所、または最も関連性の高い場所で構造体を「スタック」しました...
私の特定のケースでは、特定のアプリケーションとそのクラス全体に渡される値型で明示的に構成された構造体がいくつかあるため、特定の「領域」が任意の種類を要求できるとは断言できません。所有。
1 つのクラスのみに関連する小さな構造体は、多くの場合、そのクラスと同じファイルに配置されます。同様に、1 つのクラス内で使用される小さな単純なクラスは、多くの場合、同じファイルに配置されます。これは、項目が特定のクラスに関連していることを識別し、そのクラスでグループ化する手段です。
単純ではなく (少数の値しか持たない)、単一のクラスに固有の構造体は、独自のファイルに含める必要があります。
C++ では、構造体が特定のクラスまたはインターフェイスなどによって「所有」されている場合、それを所有するものの内部型として宣言することを好みます。構造体が多くの異なるクラスで使用される共通のプロトコルである場合は、それを独自の .h ファイルに入れます。構造体が関連する小さい構造体のスイートの 1 つである場合、そのようなものの名前空間を作成し、その名前空間を提供する単一の .h ファイル内ですべての構造体を宣言します。
C# では、おそらく C++ と同等のことを行うでしょう。
構造体ごと、または関連する構造体のグループごとに個別のファイルを作成できるはずです (構造体ごとに 1 つをお勧めしますが、面倒な場合があります。それらをグループ化する場合は、慎重に名前を付けてください)。
プロジェクトが「領域」と呼ぶのに十分な大きさである場合、それらを適切に記述する構造体に 1 つ以上の名前空間を導入するのが賢明でしょう。これにより、名前の競合が回避され、コードを使用するクライアントが何がどこにあるかを覚えておくことができます。名前を修飾することは、時には苦痛に思えることもありますが、大規模なプロジェクトでは重要であり、最終的には役に立ちます。
最後に、ほとんどの大規模なプロジェクトには、上位ディレクトリまたはメッセージ インターフェイスが定義されている場所に Common フォルダーがあります。これは重要なことであり、場所にはデータ構造が保持されていることを誰もが認識できるため、明確で一貫したインターフェイスを維持するためにすべての人が使用する必要があり、時間とコストがかかる可能性のある多くの変換コードの必要性を回避できます (通常は複製も行われます! ）。
構造が複数のクラスで使用される場合は、独自のファイルに入れます。Stylecop はどちらの方法でも文句を言いません。また、リシェイパーには、構造体を独自のファイルに移動するためのリファクタリングがあります。