Moeten enums in C# hun eigen bestand hebben?

Ik heb een klasse die een opsomming gebruikt, de enum bevindt zich momenteel in een eigen bestand, wat verkwistend lijkt.

Wat is de algemene mening over opsommingen die worden geplaatst in de naamruimte van een bestand waarin ze worden gebruikt? Of moet de opsomming echt in zijn eigen cs-bestand leven?

Bewerken

Ik moet vermelden dat hoewel de klasse in kwestie deze opsommingen gebruikt, dat ook doet met externe bellers. Met andere woorden, een andere klasse kan deze opsommingen instellen. Ze worden dus niet intern in de klas gebruikt, anders zou deze vraag een no-brainer zijn.

Antwoord 1, autoriteit 100%

Ik zou niet zeggen “verspilling” (hoeveel kost een extra bestand?), maar het is vaak onhandig. Meestal is er één klasse die het meest geassocieerd is met de opsomming, en ik plaats ze in hetzelfde bestand.

Antwoord 2, autoriteit 76%

Dit is eigenlijk gewoon een kwestie van voorkeur.

Ik geef er de voorkeur aan elke opsomming in zijn eigen bestand te plaatsen (eveneens voor elke interface, klasse en struct, hoe klein ook). Het maakt ze gemakkelijker te vinden wanneer ik uit een andere oplossing kom of anderszins nog geen verwijzing naar het betreffende type heb.

Door één enkel type in elk bestand te plaatsen, wordt het ook gemakkelijker om wijzigingen in broncontrolesystemen te identificeren zonder te diffunderen.

Antwoord 3, autoriteit 56%

Dit is volledig een kwestie van stijl. Wat ik meestal doe is om een ​​bestand met de naam Enums.csin de oplossing te hebben waarin de enum-declaraties worden verzameld.

Maar ze worden meestal toch gevonden via de F12-toets.

Antwoord 4, autoriteit 45%

De vraag die je jezelf moet stellen is: is er iets over een opsommingstype in C# dat aangeeft dat ik het anders moet behandelen dan alle andere typen die ik maak?

Als de opsomming openbaar is, moet deze worden behandeld als elk ander openbaar type. Als het privé is, declareer het dan als een genest lid van de klas die het gebruikt. Er is geen dwingende reden om twee openbare typen in hetzelfde bestand te plaatsen, simpelweg omdat één een opsomming is. Het feit dat het een openbaar type is, is het enige dat telt; de smaak van het type niet.

Antwoord 5, autoriteit 26%

Een ander voordeel van het plaatsen van elk type (klasse, struct, enum) in zijn eigen bestand is bronbeheer. U kunt eenvoudig de volledige geschiedenis van het type krijgen.

Antwoord 6, autoriteit 18%

Ik plaats meestal binnen in de naamruimte en buiten de klas, zodat het gemakkelijk toegankelijk is voor andere klassen in die naamruimte, zoals hieronder.

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

Antwoord 7, autoriteit 11%

Over het algemeen geef ik er de voorkeur aan dat mijn opsommingen in hetzelfde bestand staan ​​als de klasse waarvan het hoogstwaarschijnlijk een attribuut zal zijn. Als ik bijvoorbeeld een klasse Taskheb, dan zal de enum TaskStatusin hetzelfde bestand staan.

Als ik echter opsommingen heb van meer algemene aard, bewaar ik ze contextueel in verschillende bestanden.

Antwoord 8, autoriteit 11%

Het hangt ervan af welke toegang nodig is.

Als de enum alleen door een enkele klasse wordt gebruikt, is het oké om het binnen die klasse te declareren, omdat je het nergens anders hoeft te gebruiken.

Voor opsommingen die door meerdere klassen of in een openbare API worden gebruikt, bewaar ik de definitie altijd in een eigen bestand in de juiste naamruimte. Het is veel gemakkelijker om die manier te vinden, en de strategie volgt het patroon van één object per bestand, wat ook goed te gebruiken is met klassen en interfaces.

Antwoord 9, autoriteit 7%

Ik denk dat dat afhangt van de reikwijdte van de opsomming. Als de opsomming bijvoorbeeld specifiek is voor één klasse, bijvoorbeeld gebruikt om het magische constante-scenario te vermijden, dan zou ik zeggen dat je deze in hetzelfde bestand als de klasse moet plaatsen:

enum SearchType { Forward, Reverse }

Als de opsomming algemeen is en door verschillende klassen voor verschillende scenario’s kan worden gebruikt, dan zou ik geneigd zijn om deze in een eigen bestand te plaatsen. Het onderstaande kan bijvoorbeeld voor verschillende doeleinden worden gebruikt:

enum Result { Success, Error }

Antwoord 10, autoriteit 5%

Ik heb de neiging om opsommingen in hun eigen bestand te plaatsen om een ​​heel eenvoudige reden: net als bij klassen en structs is het fijn om exactte weten waar je moet zoeken als je de definitie van een type wilt vinden: in de bestand met dezelfde naam. (Om eerlijk te zijn, in VS kun je ook altijd “Ga naar definitie” gebruiken.)

Het kan duidelijk uit de hand lopen. Een collega waar ik werk maakt zelfs aparte bestanden voor afgevaardigden.

Antwoord 11, autoriteit 5%

Een voordeel van het gebruik van een apart bestand voor enums is dat je de oorspronkelijke klasse die de enum gebruikte, kunt verwijderen en een nieuwe klasse kunt schrijven met de enum.

Als de enum onafhankelijk is van de originele klasse, maakt het plaatsen in een apart bestand toekomstige wijzigingen gemakkelijker.

Antwoord 12, autoriteit 5%

Als u de USysWare File Browser-invoegtoepassing voor Visual Studio gebruikt, kunt u zeer snel bestanden met bepaalde namen in uw oplossing vinden. Stelt u zich eens voor dat u zoekt naar een opsomming die niet in zijn eigen bestand staat, maar in plaats daarvan in een bestand is begraven in een gigantische oplossing.

Voor kleine oplossingen maakt het niet uit, maar voor grote wordt het des te belangrijker om klassen en opsommingen in hun eigen bestanden te houden. U kunt ze snel vinden, bewerken en meer. Ik raad je ten zeerste aan om je opsomming in een eigen bestand te plaatsen.

En zoals gezegd… Hoe verkwistend is een bestand dat toch maar een paar kb is?

Antwoord 13, autoriteit 5%

Heel eenvoudig groot voordeel om bestand te scheiden. Wanneer een object zich in zijn eigen MyObjectName.cs-bestand bevindt… kunt u naar de oplossingsverkenner gaan en MyObjectName.cs typen en precies 1 bestand te zien krijgen. Alles wat debuggen beter maakt, is leuk.

Nog een gelijkaardig voordeel: als je in alle bestanden (ctrl+shft+F) zoekt naar een naam, vind je 20 verwijzingen naar de naam in hetzelfde bestand… en die gevonden naam zal deel uitmaken van verschillende objecten. In het venster Zoekresultaten ziet u alleen het regelnummer en de bestandsnaam. Je zou het bestand moeten openen en scrollen om erachter te komen in welk object de gevonden referentie zich bevond.

Alles wat het debuggen makkelijker maakt, vind ik leuk.

Antwoord 14, autoriteit 4%

Als u meerdere projecten in één oplossing heeft. Maak dan beter een ander project Utilitiesaan. Maak vervolgens een map \Enumerationsaan en maak een geneste static classaan. En wijs vervolgens elke statische klasse toe waar u een opsomming maakt die overeenkomt met de naam van uw projecten. U hebt bijvoorbeeld een project met de naam DatabaseReader en DatabaseUsers, dan kunt u de statische klasse een naam geven zoals

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
}

Vervolgens wordt de volledige opsomming die in de volledige oplossingen per project kan worden gebruikt, erop gedeclareerd. Gebruik #regionom elk probleem te scheiden. Hierdoor is het gemakkelijker om naar opsommingen te zoeken

Antwoord 15

Ik wil graag één openbaar enums-bestand met de naam E hebben dat elke afzonderlijke opsomming bevat, dan kan elke enum worden geopend met E… en ze zijn op één plek te beheren.