When are booleans better than integers?

In most programming languages, 1 and 0 can be used instead of True and False. However, from my experience, integers seem to always be easier to use.

Here are some examples of what I mean:

if x is True: x = False
else: x = True

vs

x = abs(x-1)

__

if x is False: a = 0
else: a = 5

vs

a = 5*x

In what cases a开发者_运维技巧re booleans simpler/more efficient to use than 1 or 0?

You should always use any boolean built-in type for boolean values in high-level languages. Your second example would be a horror to debug in the case that x is true, but equal to a value different from 1, and a tricky one to figure out for any developer new to the code - especially one not familiar with your coding style. What's wrong with

x = !x;

or

a = x ? 5 : 0;

One example where an integer could be more efficient than a boolean would be in a relational database. A bit column generally can't be indexed (I can't necessarily speak for all databases on that statement, hence "generally"), so something like a tinyint would make more sense if indexing is required.

Keep in mind that, depending on the use and on the system using it, while a boolean "takes less space" because it's just a single bit (depending on the implementation), an integer is the native word size of the hardware. (Certain systems likely use a full word for a boolean, essentially saving no space when it actually runs on the metal, just to use a simple word size.)

In high-level programming languages, the choice between a boolean and an int is really more of code readability/supportability than one of efficiency. If the values are indeed limited to "true" or "false" then a boolean makes sense. (Is this model in a given state, such as "valid," or is it not? It will never be a third option.) If, on the other hand, there are currently two options but there could be more someday, it might be tempting to use a boolean (even just "for now") but it would logically make more sense to use an int (or an enum).

Keep that in mind also when doing "clever" things in code. Sure, it may look sleeker and cooler to do some quick int math instead of using a boolean, but what does that do to the readability of the code? Being too clever can be dangerous.

For readibility and good intentions, it's always better to choose booleans for true/false.

You know that you have only two possible choices. With integers, things can get a bit tricky, especially if you're using 0 as false and anything else as true.

You can get too clever when using integers for true/false, so be careful.

Using booleans will make your intentions clearer to you 6 months later and other people who will maintain your code. The less brain cycles you have to use, the better.

I'd say in your examples that the boolean versions are more readable (at least as far as your intentions). It all depends on the context too. If you're sacrificing readability in an attempt to make micro optimizations, that's just evil.

I'm not sure about efficiency but I prefer booleans in many cases.

Your first example could be easily written as x = !x and x = abs(x-1) looks really obscure to me.

Also when using integers, you can't really be sure if x is 1 and not 2 or -5 or anything. When using booleans, it's always just true or false.

It's always more efficient to use Boolean because it's easier to process and uses less processing/memory. Whenever possible, use Boolean

Booleans obviously can only accept true/false or 0/1, not only that they use less processing power and memory as Webnet has already stated.

Performance points aside, I consider booleans and integers to be two fundamentally different concepts in programming. Boolean represents a condition, an integer represents a number. Bugs are easy to introduce if you don't strictly keep the value of your integer-boolean 0 or not 0, and why bother even with that when you can just use booleans, that allow for compile-time security / typechecking? I mean, take a method:

doSomething(int param)

The method alone does /not/ imply the param is interpreted as a boolean. Nobody will stop me from passing 1337 to it, and nobody will tell me what'll happen if I do - and even if it's clearly documented not to pass the 1337 value to the method (but only 0 or 1), I can still do it. If you can prevent errors at compile time, you should.

doSomething(bool param)

only allows two values: true and false, and neither are wrong.

Also, your examples about why integers would be better than booleans are kinda flawed.

if x is True: x = False
else: x = True

could be written as

x != x

whereas your integer alternative:

x = abs(x-1)

would require me to know:

• What possible values x can have
• what the abs() function does
• why 1 is subtracted from x
• what this actually /does/. What does it do?

Your second example is also a big wtf to me.

if x is False: a = 0
else: a = 5

could be written as:

a = (x) ? 5 : 0;

whereas your integer alternative

a = 5*x

again requires me to know:

• What is X?
• What can X be?
• What happens if x = 10? -1? 2147483647?

Too much conditionals. Use booleans, for both readability, common sense, and bug-free, predictable code.

I love booleans, so much more readable and you've basically forced a contract with the user.

E.g. "These values are ONLY TRUE or FALSE".