Sollten Enums in C # eine eigene Datei haben? [geschlossen]

Ich habe eine Klasse, die eine Aufzählung verwendet. Die Aufzählung befindet sich derzeit in einer eigenen Datei, was verschwenderisch erscheint.

Wie ist die allgemeine Meinung zu Aufzählungen, die im Namespace einer Datei platziert werden, in der sie verwendet werden? Oder sollte die Aufzählung wirklich in einer eigenen CS-Datei leben?

Bearbeiten

Ich sollte erwähnen, dass die betreffende Klasse diese Aufzählungen verwendet, aber auch externe Anrufer. Mit anderen Worten, eine andere Klasse kann diese Aufzählungen festlegen. Sie werden also nicht intern in der Klasse verwendet, sonst wäre diese Frage ein Kinderspiel.

Ich würde nicht "verschwenderisch" sagen (wie viel kostet eine zusätzliche Datei?), Aber es ist oft unpraktisch. Normalerweise gibt es eine Klasse, die am engsten mit der Aufzählung verbunden ist, und ich habe sie in dieselbe Datei eingefügt.

Dies ist wirklich nur eine Frage der Präferenz.

Ich ziehe es vor, jede Aufzählung in eine eigene Datei zu stellen (ebenfalls für jede Schnittstelle, Klasse und Struktur, egal wie klein sie ist). Dies erleichtert das Auffinden, wenn ich von einer anderen Lösung komme oder auf andere Weise noch keinen Verweis auf den betreffenden Typ habe.

Das Einfügen eines einzelnen Typs in jede Datei erleichtert auch das Erkennen von Änderungen in Versionsverwaltungssystemen, ohne sich zu unterscheiden.

Dies ist eine Frage des Stils. Ich neige dazu, eine Datei Enums.csin der Lösung aufzurufen, in der die Enum-Deklarationen gesammelt werden.

Aber sie werden normalerweise F12trotzdem über den Schlüssel gefunden.

Die Frage, die Sie sich stellen sollten, lautet: Gibt es irgendetwas an einem Aufzählungstyp in C #, das angibt, dass ich ihn anders behandeln sollte als alle anderen von mir erstellten Typen?

Wenn die Aufzählung öffentlich ist, sollte sie wie jeder andere öffentliche Typ behandelt werden. Wenn es privat ist, deklarieren Sie es als verschachteltes Mitglied der Klasse, die es verwendet. Es gibt keinen zwingenden Grund, zwei öffentliche Typen in dieselbe Datei aufzunehmen, nur weil einer eine Aufzählung ist. Die Tatsache, dass es sich um einen öffentlichen Typ handelt, ist alles, was zählt; der Geschmack des Typs nicht.

Ein weiterer Vorteil des Einfügens jedes Typs (Klasse, Struktur, Aufzählung) in eine eigene Datei ist die Quellcodeverwaltung. Sie können leicht den gesamten Verlauf des Typs abrufen.

Ich platziere meistens innerhalb des Namespace und außerhalb der Klasse, damit andere Klassen in diesem Namespace wie unten leicht darauf zugreifen können.

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

Im Allgemeinen bevorzuge ich, dass sich meine Aufzählungen in derselben Datei wie die Klasse befinden, von der es höchstwahrscheinlich ein Attribut sein wird. Wenn ich zum Beispiel eine Klasse habe, befindet sich Taskdie Aufzählung TaskStatusin derselben Datei.

Wenn ich jedoch allgemeinere Aufzählungen habe, behalte ich sie kontextbezogen in verschiedenen Dateien.

Dies hängt davon ab, welcher Zugriff benötigt wird.

Wenn die Aufzählung nur von einer einzelnen Klasse verwendet wird, ist es in Ordnung, sie innerhalb dieser Klasse zu deklarieren, da Sie sie nirgendwo anders verwenden müssen.

Bei Aufzählungen, die von mehreren Klassen oder in einer öffentlichen API verwendet werden, behalte ich die Definition immer in einer eigenen Datei im entsprechenden Namespace. Es ist viel einfacher, diesen Weg zu finden, und die Strategie folgt dem Muster eines Objekts pro Datei, das auch für Klassen und Schnittstellen gut geeignet ist.

Ich denke, das hängt vom Umfang der Aufzählung ab. Wenn die Aufzählung beispielsweise für eine Klasse spezifisch ist, beispielsweise um das Szenario der magischen Konstante zu vermeiden, würde ich sagen, dass sie in dieselbe Datei wie die Klasse eingefügt wird:

enum SearchType { Forward, Reverse }

Wenn die Aufzählung allgemein ist und von mehreren Klassen für verschiedene Szenarien verwendet werden kann, würde ich sie gerne in eine eigene Datei einfügen. Zum Beispiel könnte das Folgende für verschiedene Zwecke verwendet werden:

enum Result { Success, Error }

Ich neige dazu, Enums aus einem sehr einfachen Grund in ihre eigene Datei einzufügen: Wie bei Klassen und Strukturen ist es schön zu wissen , wo genau gesucht werden muss, wenn Sie die Definition eines Typs finden möchten: in der gleichnamigen Datei. (Um fair zu sein, können Sie in VS auch immer "Gehe zur Definition" verwenden.)

Offensichtlich kann es außer Kontrolle geraten. Ein Kollege, bei dem ich arbeite, erstellt sogar separate Dateien für Delegierte.

Ein Vorteil der Verwendung einer separaten Datei für Aufzählungen besteht darin, dass Sie die ursprüngliche Klasse, die die Aufzählung verwendet hat, löschen und mithilfe der Aufzählung eine neue Klasse schreiben können.

Wenn die Aufzählung unabhängig von der ursprünglichen Klasse ist, erleichtert das Ablegen in einer separaten Datei zukünftige Änderungen.

Wenn Sie das USysWare-Dateibrowser-Add-In für Visual Studio verwenden, können Sie Dateien mit bestimmten Namen in Ihrer Lösung sehr schnell finden. Stellen Sie sich vor, Sie suchen nach einer Aufzählung, die nicht in einer eigenen Datei enthalten ist, sondern in einer Datei in einer gigantischen Lösung vergraben ist.

Für kleine Lösungen spielt es keine Rolle, aber für große wird es umso wichtiger, Klassen und Aufzählungen in ihren eigenen Dateien zu behalten. Sie können sie schnell finden, bearbeiten und vieles mehr. Ich empfehle dringend, Ihre Aufzählung in eine eigene Datei zu stellen.

Und wie gesagt ... Wie verschwenderisch ist eine Datei, die sowieso nur ein paar KB groß ist?

Sehr einfach großer Vorteil, Datei zu trennen. Wenn sich ein Objekt in einer eigenen MyObjectName.cs-Datei befindet, können Sie zum Lösungs-Explorer gehen und MyObjectName.cs eingeben und genau 1 Datei anzeigen. Alles, was das Debuggen besser macht, ist schön.

Ein weiterer Vorteil in ähnlicher Weise: Wenn Sie alle Dateien ( ctrl+ shft+ F) nach einem Namen durchsuchen , finden Sie möglicherweise 20 Verweise auf den Namen in derselben Datei ... und dieser gefundene Name ist Teil verschiedener Objekte. Im Fenster Ergebnisse suchen sehen Sie nur die Zeilennummer und den Dateinamen. Sie müssten die Datei öffnen und einen Bildlauf durchführen, um herauszufinden, in welchem ​​Objekt sich die gefundene Referenz befindet.

Alles, was das Debuggen erleichtert, gefällt mir.

Wenn Sie mehrere Projekte in einer Lösung haben. Dann erstellen Sie besser ein anderes Projekt Utilities. Erstellen Sie dann einen Ordner \Enumerationsund erstellen Sie einen verschachtelten static class. Weisen Sie dann jeder statischen Klasse zu, in der Sie eine Aufzählung erstellen, die dem Namen Ihrer Projekte entspricht. Wenn Sie beispielsweise ein Projekt mit dem Namen DatabaseReader und DatabaseUsers haben, können Sie die statische Klasse wie folgt benennen

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

}

Dann wird die gesamte Aufzählung deklariert, die in den gesamten Lösungen pro Projekt verwendet werden kann. Verwenden Sie # region, um jedes Problem zu trennen. Auf diese Weise ist es einfacher, nach Aufzählungen zu suchen

Ich möchte eine öffentliche Aufzählungsdatei mit dem Namen E haben, die jede separate Aufzählung enthält. Dann kann auf jede Aufzählung mit E zugegriffen werden ... und sie befinden sich an einem Ort, an dem sie verwaltet werden können.