I recommend you don't use booleans in your code. Always prefer an enum, even if for now you are only supporting values TRUE and FALSE. In the future you almost always will have more states, and if you wrote your whole application around a boolean you're going to be in for an annoying refactor. Just start with enum from the beginning. It doesn't hurt you at all to do this, and it means you can refactor more easily.
Maybe you have a device that connects to another device over bluetooth or wifi or anything. You might be tempted to say: bool isConnected = false This is the wrong approach. Eventually you will want to have "is connected", "not connected", "poor connection", "fast connection", "is connectING", "is disconnectING" and more. Instead you should
enum ConnectionStatus{ Connecting, Connected, Disconnected, etc.. }
This is true for so many things . If you're pet app was originally designed to be about dogs and cats, you might have had a field "bool isDog = true;". When you start supporting iguanas in your app, every single method call, database field, etc. that used a bool will need to change.
If you write a navigation app, you could have a field "bool isWalking = false; // user will drive.". This implies that the user is either walking or driving. What about public transportation? What about when then need to cross water?! Should have used an enum for this field, not a bool.
Countless times this has hurt me in my career. We support a product at a company I work for, but then the boss wants to support a second product in the software. Back when I was a baby programmer, I went and added bools to my code. "if product.isTypeA {do stuff} else {do other stuff}". Big mistake. Baby me didn't know that the manager was planning to release 12 different products. After refactoring the app to support 2 products, you will shortly have to extend it to support 3. Then 4, 5, etc..
At the FIRST WHIFF of something being true or false, your instinct ought to be to use an enum and expect your manager, client, whoever, to eventually ask you support more than true/false states.
Other people have said this too, I think I've seen Uncle Bob talk about this, but he goes on to talk about polymorphism as well. If you're doing OOP, also be sure to take advantage of polymorphism when applicable. But thats another story for another day.
OH! And of course sometimes you HAVE to use a boolean. Like "is the button activated in my UI?" The answer to this is a boolean answer. But if you are able, you should always prefer an enum. Even if it's values are just TRUE and FALSE.