When is boolean better than integers?

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

Here are some examples of what I mean:

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

against

 x = abs(x-1) 

__

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

against

 a = 5*x 

When is Boolean easier / more efficient to use than 1 or 0?

+6
int theory boolean
source share
9 answers

One example where an integer might be more efficient than a boolean would be in a relational database. A bit column usually cannot be indexed (I cannot talk about all the databases of this operator, therefore, "generally"), so something like tinyint makes sense if indexing is required.

Keep in mind that depending on the use and the system used, while the logical one takes up less space, because it is just one bit (depending on implementation), the integer is the native word size at the hardware level, (Some systems probably use the full word for a logical one, essentially not saving space when it really works on metal, just to use a simple word size.)

In high-level programming languages, the choice between logical and int code is actually more of code / support readability than efficiency. If the meanings are truly limited to true or false, then logical makes sense. (Is this model in a certain state, for example, “real” or not? This will never be the third option.) If, on the other hand, there are currently two options, but there may be more someday, it would be tempting to use a logical (even just “for now”), but logically it makes sense to use int (or enumeration).

Keep this in mind when doing smart things in code. Of course, it may look more elegant and colder to do some quick math instead of using logical, but what does it do with code readability? Being too smart can be dangerous.

+7
source share

You should always use any logical built-in type for boolean values ​​in high-level languages. Your second example is the horror for debugging if x is true but equal to a value other than 1, and difficult to figure out which new developer is new to the code - especially one that is not familiar with your coding style. What is wrong with

 x = !x; 

or

 a = x ? 5 : 0; 
+11
source share

For readability and good intentions, it is always better to choose boolean values ​​for true / false.

You know that you have only two possible options. With integers, things can get a little complicated, especially if you use 0 as false and something else as true.

You can get too smart if you use integers for true / false, so be careful.

Using booleans will make your intentions clearer for you 6 months later and for other people who will support your code. The fewer brain cycles you should use, the better.

+6
source share

I would say in your examples that logical versions are more readable (at least as far as your intentions are). It all depends on the context. If you sacrifice readability while trying to do micro-optimizations, this is just evil.

+4
source share

I'm not sure about the efficiency, but in many cases I prefer Boolean.

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

Also, when using integers, you cannot be sure that x is 1, not 2 or -5 or something else. When using boolean, it is always true or false.

+1
source share

Using Boolean is always useful because it is easier to process and uses less processing / memory. Use Boolean whenever possible

0
source share

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

0
source share

Distinctive features of performance, I believe that logical and integer numbers are two fundamentally different concepts in programming. Boolean represents a condition; an integer represents a number. Errors are easily injected if you do not strictly keep the value of your integer-boolean 0 or not 0, and why bother even when you can just use boolean values ​​that allow you to perform security / type checking? I mean, take a method:

 doSomething(int param) 

Only one method / not / implies that the parameter is interpreted as boolean. Nobody will stop me from going through the year 1337, and no one will tell me what will happen if I do this - and even if he clearly documented so as not to pass the value 1337 to the method (but only 0 or 1), I can still This . If you can prevent errors during compilation, you should.

doSomething (bool param)

allows only two values: true and false, as well as incorrect.

Also, your examples of why integers would be better than booleans are incorrect.

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

can be written as

 x != x 

while your whole alternative is:

 x = abs(x-1) 

would require me to know:

  • What possible values ​​of x can have
  • what the abs () function does
  • why 1 is subtracted from x
  • what it really is / does /. What is he doing?

The second example is big wtf for me.

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

can be written as:

a = (x)? fifty;

while your whole alternative

 a = 5*x 

again requires me to know:

  • What is X?
  • What could be X?
  • What happens if x = 10? -one? 2147483647?

Too many conventions. Use booleans for readability as well as common sense and error free predictable code.

0
source share

I like booleans, so readable, and you basically made a contract with the user.

eg. "These values ​​are ONLY TRUE or FALSE."

0
source share

All Articles