DEV Community

Cover image for Boolean - The Good, The Bad and there is no place for the Ugly

Boolean - The Good, The Bad and there is no place for the Ugly

Pragmatic Maciej on June 27, 2019

Bool, Boolean, we all know that type. It is a primitive type in every programming language I know. Bool is a type containing two possible values - ...
Collapse
 
samholmes profile image
Sam Holmes

If the application deals with admins and non-admins, then booleans are just fine. If you're application deals with more than two states for a "user type", then use a enumerable data type. Booleans are just fine when used properly.

Collapse
 
macsikora profile image
Pragmatic Maciej

Hi Sam. Thanks for the comment.
Yes Booleans are fine. But I see in this particular example and in many others even for two possible values I would choose some Union type. The reason is that Bool is not informative enough. So if you have property isAdmin and it is false, then you know that the user is not an admin, but who is the user, still you don't know.

And by custom type (enum, union) it can be easily defined. So I can set a type like (not TS notation) Admin | Manager or Admin | Client and so on. And I can define who is this second part. I know then, not only that somebody is not an admin, but I know who exactly he is.

In other words, such type gives identity to every option existing in our type.

Collapse
 
qm3ster profile image
Mihail Malo

I think you accidentally wrote

type User {
  /* props */
}

instead of

interface User {
  /* props */
}

in most your code examples.

Collapse
 
macsikora profile image
Pragmatic Maciej

Nope, it was intentional, but I did an error in syntax. Thanks! There is = sign missing. Will fix it. Thanks again

Collapse
 
qm3ster profile image
Mihail Malo

That's an option as well.
I tend to use interface whenever possible however, because (at least in the past) there were edge cases where the typechecking is more strict.
Plus, the error messages are also clearer.

Collapse
 
caleb_rudder profile image
Caleb Rudder

This is Great! In my applied algorithms class we had many cases and at the beginning of that semester my code was awful and littered with if statements and boolean values. However, I learned rather quickly (with the help of the prof) the efficiency and cleanliness of custom data types and structs.

Collapse
 
srobfr profile image
srobfr • Edited

This works well until the business says that a Thing in your model can be updated only by (Managers) and (Normal users that own this Thing).
Then you have to bin all this and implement a roles system with an access control list.
This is the normal life of an evolving project...

Collapse
 
macsikora profile image
Pragmatic Maciej

Users and roles was only naive example. Not like I wanted to go deeper in that domain, it was just for me natural fit to show the problem in clean way.

Collapse
 
srobfr profile image
srobfr

You did it very well :)
Also, boolean function arguments are often considered a code smell, as they are mostly used to implement things that should be done with the Strategy design pattern.

Collapse
 
mrlarson2007 profile image
Michael Larson

Just one thing would like to mention, this is a great example where boolean flag would not be a good idea, but what if we where guaranteed that there only be admins and non admins and nothing else? We have to make trade offs all the time and there may be cases where a boolean flag is just fine.

Collapse
 
macsikora profile image
Pragmatic Maciej

Yes true, we make trade off all the time. I think in this particular example even for two options, type like: Admin | User would be just more readable. But even though you would choose Bool for that, then most important is to know when to turn back. The moment here would be any first situation when you need to create a second Bool, this should be a red light, it indicates that our data is wrongly modeled.