A received this email from a friend:
I’m fighting with the tech lead of another team. Among the many issues, he wants to use an enum with 2 values: APPROVED and UNAPPROVED. During code review, our team suggested using a boolean. He refuses. Now, we have to escalate this pointless issue to a meeting involving 3 engineers, 3 managers, and a program manager.
Without any additional information, I would agree with the tech lead, for these reasons:
Often you later want to add more states, and it can be difficult or impossible to do that to a boolean. In this case there may be more states like “in review” or whatever (think of the Apple App Store submission states).
With a boolean it’s not always clear what the false state means.
In this case, if you have an approved boolean, does false mean “not
yet approved” or “denied”? With an enum you can call them APPROVED and
DENIED or whatever to make it clear. (I would not call it UNAPPROVED.
I would use a positive term.)
When passing parameters to a function, it’s much clearer to use
an enum. Consider something like, addItem(name, true) vs.
addItem(name, APPROVED).
The enum is type-safe: You don’t risk swapping two parameters by accident, which you might do if they were both boolean flags.
I just ran into this problem last week. Years ago we had added a
preference for the way that a list was sorted. We
added a boolean sortAlphabetically. It certainly had drawback 1 when
I had to add a third way to sort. It also had drawback 2 because what
does false mean? Turns out it meant chronologically, but that’s not
obvious.
There are sometimes cases where logically something can only be a boolean, but in most cases an enum is clearer and more future-proof.
There’s a related user-interface maxim with radio buttons and checkboxes. See Don’t Use Checkboxes.