Enums vs string constants c#
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
|
show 1 more comment
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
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" asEnum.GetValues(typeof(TheEnum)).Cast<TheEnum>()
– Corak
Nov 24 '18 at 6:49
|
show 1 more comment
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
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
c# design-patterns
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" asEnum.GetValues(typeof(TheEnum)).Cast<TheEnum>()
– Corak
Nov 24 '18 at 6:49
|
show 1 more comment
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" asEnum.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
|
show 1 more comment
1 Answer
1
active
oldest
votes
Just because something can be abused doesn't mean its bad to use.
you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Just because something can be abused doesn't mean its bad to use.
you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.
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
add a comment |
Just because something can be abused doesn't mean its bad to use.
you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.
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
add a comment |
Just because something can be abused doesn't mean its bad to use.
you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.
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
Just because something can be abused doesn't mean its bad to use.
you gave no realistic use cases, and just foo examples its hard to tell if this smells or not.
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
answered Nov 24 '18 at 3:29
Michael RandallMichael Randall
31.6k63565
31.6k63565
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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