Why enums are bad

If this was a value coming from a data source of some sort, we have some ambiguity in our application. But why stop at strings?

In fact, we can mix and match the values of enums within an enum itself:. Provided that all assignable values are of the same type numeric in this case we can generate those numbers in a bunch of different ways, including computed values, but if they are all constants, we can mix types to make a heterogeneous enum:.

Enums in TypeScript are a very useful addition to the JavaScript language when used properly. I know it seems that there are a lot of things, such as gender that will never change, but they could, and that is why we need a database model that can handle. A big problem is that if you misspell a constant of variable you will find out really soon because the code will not compile. If you misspell and enum, or if the enum text is changed then the code needs to be changed. This is because we are mixing up the identity and the description.

Two distinct values within the database may have a different identity but for display purposes they may be the same. Decoding and display of data is something that needs to be performed in the view. The model should only model the data.

I really appreciate all the comments you guys are currently giving about this topic. But I must say that some of the comments are rather rude against the author.

Some agree and some might not agree…. I personally think of enums not as plain evil programming construct but I think that enums can be safely used in code structures internally. Especially for frameworks that should be designed for extensibility the usage of enums should be avoided because polymorphism is the way to go.

If your any additional values would require your application to change, then you need a constant, or Enum for that matter. Example, addition of status to a certain type of record, which probably needs extra logics. If any addition of additional values should not affects how the application works as in, just another value , then use reference files.

Example, additional ISO currency value, which should not affects on how the application works. And one should not expose internationalization concerns to Enums. I can assure you that I hate enums as well. They have no place in an object oriented language.

Every time I see enums used, a lot of spaghetti code has evolved around it because they simply are very stupid to build anything useful around. Should it max out the speaker volume? Mute it? Treat it as though it were set to some system-wide default? My brother pointed me to this when he asked if using an enum in a switch statement for control flow was bad code.

Enum classes would be a nightmare in certain situations such as serialization. We use them in WCF, mobile clients and other web services without issue for years now where millions upon millions of transactions are processed. Yes, enum classes have their place but making a blanket claim IMO displays a serious lack of knowledge or experience in the real world.

Personally, I have never seen the point of enumeration in languages with definable data structures — they just seem to be completely unnecessary layer of abstraction! Increased code readability is a highly dubious argument to support their use — defines work just fine for me. Use enums with caution. Now try to call new EnumTricks. IsVolumeHigh Volume 27 ; That should fail, at least at runtime. Low: Console. WriteLine "Volume is low. Show 6 more comments. When transmitting data enums are no code smell IMHO, when transmitting data using enums to indicate that a field can have a value from a restricted seldom changing set of values is good.

Are switch statements bad? Having switches on an enum all over the place is a code smell, oop provides alternatives that are often better: Use object of different classes of a hierarchy that have overridden methods; i. Use the visitor pattern when the classes in the hierarchy seldom change and when the many operations should be loosely coupled to the classes in the hierarchy.

Kasper van den Berg Kasper van den Berg 2, 14 14 silver badges 29 29 bronze badges. Actually, TickType is being transmitted thru the wire as an int. My wrapper is the one that uses TickType which is casted from the received int.

Several events use this ticktype with wild varying signatures that are responses to various requests. Is it common practice to have use an int continously for different functions? TickPrice int type, double value uses 1,3, and 6 for type while TickSize int type, double value uses 2,4, and 5?

Does it even make sense to separate those into two events? One switch, ideally in a factory, is fine. More than one is bad, and the more of them there are, the worse it is. Add a comment. There are two simple options: Organize the code according to the operations. In this case you can use an enumeration to tag different types, and have a switch statement in each procedure that uses the tagged data. Organize the code according to the data types.

In this case you can replace the enumeration by an interface and use a class for each element of the enumeration. You then implement each operation as a method in each class. Which solution is better? Bottomline: enums are not necessarily a code smell. Giorgio Giorgio 19k 16 16 gold badges 78 78 silver badges bronze badges. DaveCousineau: "I don't see one as being "better" than the other as you describe": I did not say that one is always better than the other.

I said that one is better than the other depending on the context. I don't see either as being "better" as you described meaning that I don't see that it depends on the situation. The amount of code you have to write is exactly the same in both scenarios. The only difference is that one way is antithetical to OOP enums and one isn't. DaveCousineau: "Adding 1 method to 10 existing files or 10 methods to 1 new file.

If your intuition is different, we do not need to discuss any further. OOP is a tool, not an inherent quality of righteousness in the world.

So if the only difference is that one is anti-OOP and the other isn't, then we could indeed say that they're fully equivalent. FWIW, I would also consider adding one new class to be a smaller and safer change than altering a large number of existing ones, because the latter opens up the possibility of regressions across the entire program, whereas in the former bugs will be local to the newly added operation. Show 3 more comments. The two major problems with enums are: They are often used in situations where polymorphism would make a lot more sense, would be easier to extend and would lead to more stable and easier to maintain code.

As a tip: Never store enums persistently. Mecki Mecki 1, 8 8 silver badges 14 14 bronze badges. TL;DR To answer the question, I'm now having a hard time thinking of a time enums are not a code smell on some level. Excuse me as I refactor tons of my legacy code. Whaddya know, the enum and switch were likely code smells.

Step 3: Profit. How about the case where, e. I think the key thing is that the enum is used for orchestration, not as an implementation of conditional logic. AntP Why not, in this case, use the StatusResult value? You could argue that the enum is useful as a human-memorable shortcut in that use case, but I'd probably still call that a code smell, as there are good alternatives that don't require the closed collection. What alternatives? A string?

That's an arbitrary distinction from the perspective of "enums should be replaced with polymorphism" - either approach necessitates mapping a value to a type; avoiding the enum in this case achieves nothing. AntP I'm not sure where the wires are crossing here.