C＃の列挙型には独自のファイルが必要ですか？[閉まっている]

列挙型を使用するクラスがあります。列挙型は現在、独自のファイルにあり、無駄に見えます。

列挙型が消費されるファイルの名前空間内に配置される列挙型に関する一般的な意見は何ですか？または、列挙型は実際に独自のcsファイルに存在する必要がありますか？

編集する

問題のクラスがこれらの列挙を使用する一方で、外部の呼び出し元も使用することを述べておかなければなりません。つまり、別のクラスがこれらの列挙を設定できます。したがって、これらはクラスの内部では使用されません。それ以外の場合、この質問は簡単です。

「無駄」とは言いませんが（追加のファイルにいくらかかりますか？）、それはしばしば不便です。通常、列挙型と最も密接に関連しているクラスが1つあり、それらを同じファイルに配置します。

これは本当に好みの問題です。

私はそれぞれの列挙を独自のファイルに置くことを好みます（どのように小さくても、各インターフェース、クラス、および構造体について同様です）。別のソリューションを使用している場合や、問題の型への参照がまだない場合に、見つけやすくなります。

また、各ファイルに単一のタイプを入れると、ソース管理システムの変更を区別することなく簡単に識別できます。

これは完全にスタイルの問題です。私がしがちなことはEnums.cs、列挙型宣言が収集されるソリューションでファイルを呼び出すことです。

しかし、それらは通常、F12とにかくキーを介して見つかります。

自問する質問は次のとおりです。C＃の列挙型について、他のすべての型とは異なる扱いをする必要があることを示すものはありますか？

列挙がパブリックの場合、他のパブリックタイプと同様に扱う必要があります。プライベートの場合は、それを使用するクラスのネストされたメンバーとして宣言します。1つが列挙型であるという理由だけで、2つのパブリックタイプを同じファイルに入れる理由はありません。それがパブリックタイプであるという事実はすべての問題です。タイプのフレーバーはしません。

各タイプ（クラス、構造体、列挙型）を独自のファイルに配置するもう1つの利点は、ソース管理です。タイプの履歴全体を簡単に取得できます。

以下のように、その名前空間内の他のクラスに簡単にアクセスできるように、主に名前空間内とクラス外に配置します。

namespace UserManagement
{
    public enum UserStatus { Active, InActive }
    class User
    {
        ...
    }
}

一般に、列挙型はクラスと同じファイルにあることをお勧めします。それはおそらくそれが属性になるでしょう。たとえば、クラスがあるTask場合、列挙型TaskStatusは同じファイルにあります。

ただし、より一般的な性質の列挙型がある場合は、状況に応じてさまざまなファイルに保持します。

どのアクセスが必要かによって異なります。

enumが単一のクラスでのみ使用される場合は、他の場所で使用する必要がないため、そのクラス内で宣言しても問題ありません。

複数のクラスまたはパブリックAPIで使用される列挙型の場合は、適切な名前空間の独自のファイルに定義を常に保持します。その方法を見つけるのははるかに簡単で、戦略はファイルごとに1つのオブジェクトのパターンに従います。これは、クラスやインターフェイスでも使用するのに適しています。

それは列挙型のスコープに依存すると思います。たとえば、列挙が1つのクラスに固有である場合、たとえば、魔法の定数のシナリオを回避するために使用される場合は、クラスと同じファイルにそれを配置します。

enum SearchType { Forward, Reverse }

列挙型が一般的で、さまざまなシナリオのいくつかのクラスで使用できる場合、それを独自のファイルに入れて使用する傾向があります。たとえば、以下はいくつかの目的に使用できます。

enum Result { Success, Error }

非常に単純な理由で、列挙型を独自のファイルに入れる傾向があります。クラスや構造体と同様に、正確に知っておくと便利です場合と同様に、型の定義を検索したい場合は、同じ名前のファイルでどこを探すかを。（公平を期すために、VSでは常に「定義に移動」も使用できます。）

明らかに、手に負えなくなる可能性があります。私が働いている同僚は、代理人のために個別のファイルを作成しています。

enumに別のファイルを使用する利点の1つは、enumを使用していた元のクラスを削除し、enumを使用して新しいクラスを作成できることです。

列挙型が元のクラスから独立している場合は、それを別のファイルに入れると、将来の変更が容易になります。

Visual Studio用のUSysWare File Browserアドインを使用している場合、ソリューション内の特定の名前のファイルを非常にすばやく見つけることができます。独自のファイルではなく、巨大なソリューションのいくつかのファイルに埋め込まれている列挙型を探すことを想像してみてください。

小さなソリューションの場合は問題ありませんが、大きなソリューションの場合は、クラスと列挙型を独自のファイルに保持することがますます重要になります。それらをすばやく見つけたり、編集したりできます。enumを独自のファイルに入れることを強くお勧めします。

そして述べられたように...結局数キロバイトだけになるファイルはどれほど無駄なのでしょうか？

ファイルを分離することの非常にシンプルで大きな利点。オブジェクトが独自のMyObjectName.csファイルにある場合...ソリューションエクスプローラーに移動してMyObjectName.csと入力すると、1つのファイルのみが表示されます。デバッグを改善するものは何でもいいです。

同様のメモのもう1つの利点は、すべてのファイル（ctrl+ shft+ F）で名前を検索すると、同じファイル内にその名前への20の参照が見つかる可能性があることです。その見つかった名前は、異なるオブジェクトの一部になります。[結果の検索]ウィンドウで確認できるのは、行番号とファイル名だけです。ファイルを開いてスクロールし、見つかった参照が含まれているオブジェクトを特定する必要があります。

デバッグを容易にするものなら何でも好きです。

1つのソリューションに複数のプロジェクトがある場合。次に、別のプロジェクトを作成しますUtilities。次に、フォルダ\Enumerationsを作成し、ネストされたを作成しますstatic class。次に、プロジェクトの名前に対応する列挙型を作成する各静的クラスを割り当てます。たとえば、DatabaseReaderとDatabaseUsersという名前のプロジェクトがある場合、静的クラスに次のような名前を付けます。

public static class EnumUtility {
    #region --Database Readers Enum
    public static class EnumDBReader {
         public enum Actions { Create, Retrieve, Update, Delete}; 
    }
    #endregion

    #region --Database Users Enum
    public static class EnumDBUsers {
         public enum UserIdentity { user, admin }; 
    }
    #endregion

}

次に、プロジェクトごとのソリューション全体で使用できる列挙型全体が宣言されます。＃regionを使用して各懸念事項を区切ります。これにより、列挙型を探すのが簡単になります

Eという名前の1つの公開列挙ファイルを個別の列挙を含むようにしたいので、任意の列挙にE ...でアクセスでき、それらを1つの場所で管理できます。