You start with a Boolean to represent two possible values/states. Then your program evolves and you need represent a third state, so what do you do? Obviously you add an other Boolean.
I keep doing that and then for several weeks I deal with the extra pain and complexity this causes. Then always, and I mean always, I end up rewriting all that code using enums.
This is something I've gone through and started to think about and eventually try and help others with. Working with mulitlingual people I noticed a tendency to use negative words "disabled" instead of "enabled" which always made code have !disabled everywhere. Tried the enum approach as well; Love focused writings like this to distill a lot of information into an easy to read form. the new concept for me is the `with` as in to apply functionality by extending a `with` class (this is inside an angular project). Also using types for values so when passing a value in for methods you don't get a blank true/false you get a human readable thing which is useful for debugging and building. Only care about optimizations later if it will ever matter.
You start with a Boolean to represent two possible values/states. Then your program evolves and you need represent a third state, so what do you do? Obviously you add an other Boolean.
I keep doing that and then for several weeks I deal with the extra pain and complexity this causes. Then always, and I mean always, I end up rewriting all that code using enums.
This is something I've gone through and started to think about and eventually try and help others with. Working with mulitlingual people I noticed a tendency to use negative words "disabled" instead of "enabled" which always made code have !disabled everywhere. Tried the enum approach as well; Love focused writings like this to distill a lot of information into an easy to read form. the new concept for me is the `with` as in to apply functionality by extending a `with` class (this is inside an angular project). Also using types for values so when passing a value in for methods you don't get a blank true/false you get a human readable thing which is useful for debugging and building. Only care about optimizations later if it will ever matter.
It goes beyond just naming Booleans, all naming of variables is hard
This, but using bitfields and enums.
Using multiple booleans like this seems like such a waste unless you're using a language that doesn't let you do otherwise.