Gli enum in C # dovrebbero avere il proprio file? [chiuso]

Ho una classe che utilizza un elenco, l'enum è attualmente nel suo file che sembra dispendioso.

Qual è l'opinione generale sulle enumerazioni inserite nello spazio dei nomi di un file in cui vengono consumate? O l'enum dovrebbe davvero vivere nel proprio file cs?

modificare

Devo dire che mentre la classe in questione utilizza queste enumerazioni, anche i chiamanti esterni. In altre parole, un'altra classe può impostare queste enumerazioni. Quindi non sono usati internamente alla classe, altrimenti questa domanda non avrebbe alcun problema.

Non direi "dispendioso" (quanto costa un file extra?), Ma spesso è inconcepente. Di solito c'è una classe che è più strettamente associata all'enum e le inserisco nello stesso file.

Questa è davvero solo una questione di preferenza.

Preferisco mettere ogni enumerazione nel suo file (allo stesso modo per ogni interfaccia, classe e struttura, non importa quanto sia piccola). Li rende più facili da trovare quando vengo da un'altra soluzione o altrimenti non ho già un riferimento al tipo in questione.

Inserire un singolo tipo in ciascun file semplifica inoltre l'identificazione delle modifiche nei sistemi di controllo del codice sorgente senza differenze.

Questa è interamente una questione di stile. Quello che tendo a fare è avere un file chiamato Enums.csnella soluzione in cui sono raccolte le dichiarazioni enum.

Ma in genere si trovano F12comunque tramite la chiave.

La domanda da porsi sarebbe: c'è qualcosa in un tipo di enumerazione in C # che indica che dovrei trattarlo in modo diverso da tutti gli altri tipi che creo?

Se l'enumerazione è pubblica, deve essere trattata come qualsiasi altro tipo pubblico. Se è privato, dichiaralo come membro nidificato della classe che lo utilizza. Non vi sono motivi validi per inserire due tipi pubblici nello stesso file semplicemente perché si tratta di un elenco. Il fatto che sia di tipo pubblico è tutto ciò che conta; il sapore del tipo no.

Un altro vantaggio di mettere ogni tipo (classe, struct, enum) nel proprio file è il controllo del codice sorgente. Puoi facilmente ottenere l'intera cronologia del tipo.

Metto principalmente all'interno dello spazio dei nomi e al di fuori della classe in modo che sia facilmente accessibile altre classi nello spazio dei nomi come di seguito.

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

In genere preferisco che i miei enum siano nello stesso file della classe di cui molto probabilmente sarà un attributo. Se per esempio ho una classe, Taskallora l'enum TaskStatussarà nello stesso file.

Tuttavia, se ho enumerazioni di carattere più generico, le tengo contestualmente in vari file.

Dipende dall'accesso necessario.

Se l'enum viene utilizzato solo da una singola classe, va bene dichiararlo all'interno di quella classe perché non è necessario utilizzarlo altrove.

Per gli enum usati da più classi o in un'API pubblica, manterrò sempre la definizione nel suo file nello spazio dei nomi appropriato. È molto più facile da trovare in quel modo, e la strategia segue il modello di un oggetto per file, che è buono da usare anche con classi e interfacce.

Penso che dipenda dall'ambito dell'enum. Ad esempio, se l'enum è specifico di una classe, ad esempio utilizzato per evitare lo scenario di costante magica, direi di inserirlo nello stesso file della classe:

enum SearchType { Forward, Reverse }

Se l'enum è generale e può essere utilizzato da più classi per diversi scenari, allora sarei propenso a usarlo inserendolo nel suo file. Ad esempio, il seguito potrebbe essere utilizzato per diversi scopi:

enum Result { Success, Error }

Tendo a mettere enumerazioni nel loro file per un motivo molto semplice: come per le classi e le strutture, è bello sapere esattamente dove cercare se si desidera trovare la definizione di un tipo: nel file con lo stesso nome. (Per essere onesti, in VS puoi sempre usare anche "Vai alla definizione").

Ovviamente, può sfuggire di mano. Un collega in cui lavoro crea persino file separati per i delegati.

Un vantaggio dell'utilizzo di un file separato per enum è che puoi eliminare la classe originale che ha usato l'enum e scrivere una nuova classe usando l'enum.

Se l'enum è indipendente dalla classe originale, metterlo in un file separato rende le modifiche future più facili.

Se si utilizza il componente aggiuntivo USysWare File Browser per Visual Studio, è possibile trovare molto rapidamente file con nomi particolari nella soluzione. Immagina di cercare un enum che non è nel suo stesso file ma invece è sepolto in un file in una soluzione gigantesca.

Per le soluzioni di piccole dimensioni, non importa, ma per quelle di grandi dimensioni, diventa ancora più importante mantenere classi ed enumerazioni nei propri file. Puoi trovarli rapidamente, modificarli e altro ancora. Consiglio vivamente di mettere la tua enum in un suo file.

E come è stato affermato ... Quanto è inutile un file che finisce per essere solo un paio di kb?

Vantaggio molto semplice per separare il file. Quando un oggetto si trova nel suo file MyObjectName.cs ... puoi andare a Esplora soluzioni e digitare MyObjectName.cs e visualizzare esattamente 1 file. Tutto ciò che rende il debug migliore è bello.

Un altro vantaggio su una nota simile, se cerchi tutti i file ( ctrl+ shft+ F) per un nome, potresti trovare 20 riferimenti al nome nello stesso file ... e quel nome trovato farà parte di oggetti diversi. Nella finestra Trova risultati tutto ciò che puoi vedere è il numero di riga e il nome del file. Dovresti aprire il file e scorrere per capire in quale oggetto si trovava il riferimento trovato.

Qualunque cosa che renda più semplice il debug, mi piace.

Se hai più progetti in una soluzione. Quindi meglio creare un altro progetto Utilities. Quindi creare una cartella \Enumerationse creare un nidificato static class. E quindi assegna ogni classe statica in cui creerai enum che corrisponde al nome dei tuoi progetti. Ad esempio hai un progetto chiamato DatabaseReader e DatabaseUsers, quindi puoi nominare la classe statica come

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

}

Quindi verrà enunciato l'intero enum che può essere utilizzato nell'intera soluzione per progetto. Usa # regionper separare ogni preoccupazione. Con questo, è più facile cercare eventuali enumerazioni

Mi piace avere un file di enumerazioni pubbliche chiamato E contenente ciascuna enum separata, quindi è possibile accedere a qualsiasi enum con E ... e sono in un posto da gestire.