What I mean is: some boolean flags are perfect for the real world phenomenon they are representing e.g. is_light_on makes you understand perfectly that when it is true the light is on and when it is false the light is off.
There are other cases in which if you didn’t write the code and you don’t read any additional documentation, everything is not clear just by looking at the variable name e.g. is_person_standing, when true it’s clear what that means but when false, is the person sitting? Lying? Kneeling?
I’m obviously not talking about cases in which there are more states, boolean would of course not be a good solution in those cases. I’m talking about programs in which there are only two states but it’s not obvious, without external knowledge, which ones they are.
if the states aren’t obvious, use an enum with two values, and name them both. Thats what enums are for.
Other states are irrelevant only the true condition implied matters, it is or isn’t that one state.
is_person_standing, is_standing, bStanding all tell you if someone is standing or NOT standing. Nothing else period. It does not matter if there could be other states as the test is one specific case.
One should not use boolean just because variable has only two states.
I believe when you use boolean when enum should be used is called “boolean blindness”.
Eg: isFemale instead of enum Sex {MALE;FEMALE} It also gives you an option to simply extend code if requirements change and there are more than two options.
In your example, it’s implied that any pose other than standing is irrelevant in that context. Why do you need to care if you don’t need to care?
Maybe I explained myself poorly, what I was asking is about cases in which there are only two states e.g. standing and sitting and they are equally important so is_person_standing would not be a good name
It shouldn’t matter if the user is leaning or jumping or whatever. If the variable says “is_person_standing” then the only information I get out of it is whether the person is standing or not. It would be much simpler to use enums to represent the state if there are such other options. If you don’t have enums in your language, then use constants.
I would use an Enum if available in the language:
- More meaningful
- Extendable
- Lower chance of misuse
- No naming problem
My favorite when debugging some code for a memory manager, written in the days of DOS extended memory, was shit_cookie_corrupt.
The original author called blocks of memory “cookies”. If too many cookies were corrupted then eventually the function ohShitOhShitOhShit was called, which shut everything down.