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 - ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
isAdminand 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 | ManagerorAdmin | Clientand 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.
I think you accidentally wrote
instead of
in most your code examples.
Nope, it was intentional, but I did an error in syntax. Thanks! There is = sign missing. Will fix it. Thanks again
That's an option as well.
I tend to use
interfacewhenever 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.
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.
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...
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.
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.
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.
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.