Enums vs string constants c#












0















So I have recently read a book specifically on Dependency Injection. In this book, somewhere, it states that enums are a code smell....



I wanted to get a general consensus from SO'ers. I need to design a rather large application with some central core classes, and am seeking assistance in terms design principles that fellow SO'ers would use in this instance, before committing myself to one way or the other making it very difficult to change afterwards.



public enum Foo
{
LovelyFoo,
TerribleFoo
}


OR



Using a static class with Contants



public static class Foo
{
public const string LovelyFoo = nameof(LovelyFoo); //or "Lovely Foo";
public const string TerribleFoo = nameof(TerribleFoo); // or "Terrible Foo";
}


Then Of course using it when required



Foo MyFoo = Foo.LovelyFoo;


OR



string MyFoo = Foo.LovelyFoo;









share|improve this question

























  • Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

    – Srikanth
    Nov 24 '18 at 3:36






  • 1





    This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

    – Corak
    Nov 24 '18 at 3:43













  • "WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

    – The_Chud
    Nov 24 '18 at 4:05











  • While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

    – Corak
    Nov 24 '18 at 6:45













  • For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

    – Corak
    Nov 24 '18 at 6:49
















0















So I have recently read a book specifically on Dependency Injection. In this book, somewhere, it states that enums are a code smell....



I wanted to get a general consensus from SO'ers. I need to design a rather large application with some central core classes, and am seeking assistance in terms design principles that fellow SO'ers would use in this instance, before committing myself to one way or the other making it very difficult to change afterwards.



public enum Foo
{
LovelyFoo,
TerribleFoo
}


OR



Using a static class with Contants



public static class Foo
{
public const string LovelyFoo = nameof(LovelyFoo); //or "Lovely Foo";
public const string TerribleFoo = nameof(TerribleFoo); // or "Terrible Foo";
}


Then Of course using it when required



Foo MyFoo = Foo.LovelyFoo;


OR



string MyFoo = Foo.LovelyFoo;









share|improve this question

























  • Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

    – Srikanth
    Nov 24 '18 at 3:36






  • 1





    This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

    – Corak
    Nov 24 '18 at 3:43













  • "WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

    – The_Chud
    Nov 24 '18 at 4:05











  • While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

    – Corak
    Nov 24 '18 at 6:45













  • For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

    – Corak
    Nov 24 '18 at 6:49














0












0








0








So I have recently read a book specifically on Dependency Injection. In this book, somewhere, it states that enums are a code smell....



I wanted to get a general consensus from SO'ers. I need to design a rather large application with some central core classes, and am seeking assistance in terms design principles that fellow SO'ers would use in this instance, before committing myself to one way or the other making it very difficult to change afterwards.



public enum Foo
{
LovelyFoo,
TerribleFoo
}


OR



Using a static class with Contants



public static class Foo
{
public const string LovelyFoo = nameof(LovelyFoo); //or "Lovely Foo";
public const string TerribleFoo = nameof(TerribleFoo); // or "Terrible Foo";
}


Then Of course using it when required



Foo MyFoo = Foo.LovelyFoo;


OR



string MyFoo = Foo.LovelyFoo;









share|improve this question
















So I have recently read a book specifically on Dependency Injection. In this book, somewhere, it states that enums are a code smell....



I wanted to get a general consensus from SO'ers. I need to design a rather large application with some central core classes, and am seeking assistance in terms design principles that fellow SO'ers would use in this instance, before committing myself to one way or the other making it very difficult to change afterwards.



public enum Foo
{
LovelyFoo,
TerribleFoo
}


OR



Using a static class with Contants



public static class Foo
{
public const string LovelyFoo = nameof(LovelyFoo); //or "Lovely Foo";
public const string TerribleFoo = nameof(TerribleFoo); // or "Terrible Foo";
}


Then Of course using it when required



Foo MyFoo = Foo.LovelyFoo;


OR



string MyFoo = Foo.LovelyFoo;






c# design-patterns






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 24 '18 at 3:35









Michael Randall

31.6k63565




31.6k63565










asked Nov 24 '18 at 3:02









The_ChudThe_Chud

210212




210212













  • Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

    – Srikanth
    Nov 24 '18 at 3:36






  • 1





    This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

    – Corak
    Nov 24 '18 at 3:43













  • "WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

    – The_Chud
    Nov 24 '18 at 4:05











  • While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

    – Corak
    Nov 24 '18 at 6:45













  • For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

    – Corak
    Nov 24 '18 at 6:49



















  • Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

    – Srikanth
    Nov 24 '18 at 3:36






  • 1





    This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

    – Corak
    Nov 24 '18 at 3:43













  • "WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

    – The_Chud
    Nov 24 '18 at 4:05











  • While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

    – Corak
    Nov 24 '18 at 6:45













  • For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

    – Corak
    Nov 24 '18 at 6:49

















Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

– Srikanth
Nov 24 '18 at 3:36





Have a look at this to get an idea about the context in which enums are better than strings. softwareengineering.stackexchange.com/questions/349146/…

– Srikanth
Nov 24 '18 at 3:36




1




1





This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

– Corak
Nov 24 '18 at 3:43







This is the first time I heared that "enums are a code smell", and this feels like way too general of a statement. Could you please elaborate on the reasons the book gives for that assessment?

– Corak
Nov 24 '18 at 3:43















"WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

– The_Chud
Nov 24 '18 at 4:05





"WARNING As a rule of thumb, enums are code smells and should be refactored to polymorphic classes.8 However, they serve us well for this example."

– The_Chud
Nov 24 '18 at 4:05













While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

– Corak
Nov 24 '18 at 6:45







While it's true that there are examples where enums are (ab)used where other constructs would be better, I'd still strongly disagree with the implied "all enums are a code smell". They do have their reasons to exist and to be used. The book even seems to make one point itself: sometimes it's just easier/faster. I love DI and use it almost everywhere, but one shouldn't forget YAGNI either. -- That said, forgoing enums in favour of "constant string collections" is at least just as "bad", probably worse. For example: how do you enumerate all possible strings of one "collection"?

– Corak
Nov 24 '18 at 6:45















For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

– Corak
Nov 24 '18 at 6:49





For enums it's as "easy" as Enum.GetValues(typeof(TheEnum)).Cast<TheEnum>()

– Corak
Nov 24 '18 at 6:49












1 Answer
1






active

oldest

votes


















1















  1. Just because something can be abused doesn't mean its bad to use.


  2. you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.



  3. enums are good for tightly bound sets of things, days of the week for instance.




    • Were there is a legitimate use for switch statements

    • Where the set doesn't change and is ingrained.

    • Where (and this is circular i know) enums make sense




Let constants be constants, let enums be enums. But if you find your self wanting to use lots of enums and switches, then this is probably crying out for generics or polymorphic. Just because they look neat and typed and wonderful doesn't mean your code should be full of them.



Lastly, Run the Microsoft test over your use cases. That's to say, what would Microsoft do, where in the BCL have you seen this example, is it common, does Microsoft use them like this. Although this is no saving grace, if you find your self writing weird and wonderful structures that are unpredictable and no-one else has seen, then you are probably doing something wrong






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454812%2fenums-vs-string-constants-c-sharp%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1















    1. Just because something can be abused doesn't mean its bad to use.


    2. you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.



    3. enums are good for tightly bound sets of things, days of the week for instance.




      • Were there is a legitimate use for switch statements

      • Where the set doesn't change and is ingrained.

      • Where (and this is circular i know) enums make sense




    Let constants be constants, let enums be enums. But if you find your self wanting to use lots of enums and switches, then this is probably crying out for generics or polymorphic. Just because they look neat and typed and wonderful doesn't mean your code should be full of them.



    Lastly, Run the Microsoft test over your use cases. That's to say, what would Microsoft do, where in the BCL have you seen this example, is it common, does Microsoft use them like this. Although this is no saving grace, if you find your self writing weird and wonderful structures that are unpredictable and no-one else has seen, then you are probably doing something wrong






    share|improve this answer




























      1















      1. Just because something can be abused doesn't mean its bad to use.


      2. you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.



      3. enums are good for tightly bound sets of things, days of the week for instance.




        • Were there is a legitimate use for switch statements

        • Where the set doesn't change and is ingrained.

        • Where (and this is circular i know) enums make sense




      Let constants be constants, let enums be enums. But if you find your self wanting to use lots of enums and switches, then this is probably crying out for generics or polymorphic. Just because they look neat and typed and wonderful doesn't mean your code should be full of them.



      Lastly, Run the Microsoft test over your use cases. That's to say, what would Microsoft do, where in the BCL have you seen this example, is it common, does Microsoft use them like this. Although this is no saving grace, if you find your self writing weird and wonderful structures that are unpredictable and no-one else has seen, then you are probably doing something wrong






      share|improve this answer


























        1












        1








        1








        1. Just because something can be abused doesn't mean its bad to use.


        2. you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.



        3. enums are good for tightly bound sets of things, days of the week for instance.




          • Were there is a legitimate use for switch statements

          • Where the set doesn't change and is ingrained.

          • Where (and this is circular i know) enums make sense




        Let constants be constants, let enums be enums. But if you find your self wanting to use lots of enums and switches, then this is probably crying out for generics or polymorphic. Just because they look neat and typed and wonderful doesn't mean your code should be full of them.



        Lastly, Run the Microsoft test over your use cases. That's to say, what would Microsoft do, where in the BCL have you seen this example, is it common, does Microsoft use them like this. Although this is no saving grace, if you find your self writing weird and wonderful structures that are unpredictable and no-one else has seen, then you are probably doing something wrong






        share|improve this answer














        1. Just because something can be abused doesn't mean its bad to use.


        2. you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.



        3. enums are good for tightly bound sets of things, days of the week for instance.




          • Were there is a legitimate use for switch statements

          • Where the set doesn't change and is ingrained.

          • Where (and this is circular i know) enums make sense




        Let constants be constants, let enums be enums. But if you find your self wanting to use lots of enums and switches, then this is probably crying out for generics or polymorphic. Just because they look neat and typed and wonderful doesn't mean your code should be full of them.



        Lastly, Run the Microsoft test over your use cases. That's to say, what would Microsoft do, where in the BCL have you seen this example, is it common, does Microsoft use them like this. Although this is no saving grace, if you find your self writing weird and wonderful structures that are unpredictable and no-one else has seen, then you are probably doing something wrong







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 24 '18 at 3:29









        Michael RandallMichael Randall

        31.6k63565




        31.6k63565
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454812%2fenums-vs-string-constants-c-sharp%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Feedback on college project

            Futebolista

            Albești (Vaslui)