I’ve been writing software for a few decades and historical momentum has been to define enum values as integers, probably because earlier languages supported integers, not strings. <\/p>\n\n\n\n
\nclass Color(Enum):\n UNINITIALIZED: 0\n RED: 1\n GREEN: 2\n BLUE: 3<\/code><\/pre>\n<\/blockquote>\n\n\n\nSo it was a surprise when a discussion among engineers went the other direction — encouraging strings as enum values — for newly introduced enums. It seems that industry momentum may have shifted this direction. Here’s a contrived example that I do not recommend:<\/p>\n\n\n\n
class Color(Enum):\n UNKNOWN: \"\"\n RED: \"rood\" # Note: Dutch\n GREEN: \"verde\" # Note: Spanish\n BLUE: \"bleu\" # Note: French\n LAVINDRE: \"lavndir\" # Note: Purposefully misspelled<\/code><\/pre>\n\n\n\nBenefits of using string enum values include:<\/p>\n\n\n\n
\n
- Clarity when viewing logs. However, it is possible to log integer enum values as strings.<\/li>\n\n\n\n
- Clarity when debugging. However, some debuggers may already add clarity for integer-based enums.<\/li>\n\n\n\n
- Disparate teams across the organization can more readily understand the data without having to refer to documentation. <\/li>\n\n\n\n
- API interoperability and clarity.<\/li>\n\n\n\n
- Ease of adding new items in the middle of the enum, whereas with a sequential integer approach, it is not possible.<\/li>\n\n\n\n
- Default value as empty string. It has always been a pain when an engineer decided to use 0 to indicate anything other than “default”, “uninitialized” or “unknown”, because 0 is often the default value for uninitialized variables and properties. With strings, an empty string is ideal.<\/li>\n\n\n\n
- It’s still possible to represent string-value enums as integers when persisting to a database or interoperating with other systems — although it may require additional work.<\/li>\n<\/ul>\n\n\n\n
Caveats and counter indications:<\/p>\n\n\n\n
\n
- Legacy. Keep what works and don’t break things, especially when disparate systems depend on existing enumerated integers. Translation layers can be a solution.<\/li>\n\n\n\n
- Lack of programming language support, although there are often alternatives including use of constants.<\/li>\n\n\n\n
- When the enum string values are misnamed or poorly named, it can cause confusion and bugs due to misunderstandings.<\/li>\n\n\n\n
- Who gets do decide which human language we use for the string values? Who will be consuming the values? Do they understand the language? I gave my example above with three different language values to emphasize that it’s best to stick with a single language.<\/li>\n\n\n\n
- Misspelled values may need to remain misspelled forever to prevent breaking disparate consumers. Software engineers are human, and they make mistakes. We don’t usually misspell integer values, and when do, the software either won’t compile or won’t run. Translation layers can be a solution.<\/li>\n\n\n\n
- Upper or lower case? Camel case or snake case? Decide on a standard.<\/li>\n\n\n\n
- Performance critical systems and RAM\/storage constrained systems may do better with integer values.<\/li>\n\n\n\n
- Some databases support enums — the underlying data is an integer, and the database represents it as a string, including in queries and exports — so it could be possible to get the best of both worlds — performance and clarity for humans.<\/li>\n\n\n\n
- Isolate the churn of a ever-changing names. The integers can stay the same and the enum keys can change to reflect current needs. E.g. marketing names tend to change.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve been writing software for a few decades and historical momentum has been to define enum values as integers, probably because earlier languages supported integers, not strings. So it was a surprise when a discussion among engineers went the other direction — encouraging strings as enum values — for newly introduced enums. It seems that … <\/p>\n