Stop Using Booleans in Your Code! | Code Cop #022

Hello, everybody. I'm Nick, and in this episode of Code Cop, I will talk about boolean blindness and why it is not what the author of this LinkedIn post described.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet #codecop

[mateuszfiedorowicz]

One day the "advice" will be so horrible that at the end of the video you will say "Stop Coding".

[yorkaturr]

Clean code means readable code. If you need to come up with your own data structure for every parameter you use, it's a nightmare to debug. Maybe it's just me, but I like to use basic datatypes whenever possible. It's especially good in the backend if you can match your datatypes in code to datatypes in the database.

[brianm]

I agree with you. If the boolean is obvious (apply discount vs do not apply), then go with the boolean. If it's not obvious, like "apply discount pro-rated to all items" vs "apply discount to highest price item" (stupid example I know but best I could come up with on short notice), then an "applyDiscountToAll" boolean can be confusing, since it's not obvious what false does. Then you use an enum.

[danpaun]

avoiding boolean parameter and splitting in two functions often will mean to have the "if else" statement at an upper level :)

[easycheesy]

Enum is even more complicated because evaluating it defensively, requires checking the else (unknown) value state, to ensure a later developer hasn’t added states that your method isn’t aware of.

[smathlax]

I think in general people need to stop saying that there is any one correct way to program. Even if something is a good rule of thumb the vast majority of the time, that doesn't mean it does or should apply to every situation. Sometimes it's better to forget these "best practices" and just use your common sense.

[xhavierrhovira]

Ok, now I want a video of Nick refuting those *blergh* CleanCode™ tipes from Uncle Bob

[alexbarac]

There's a coding principle called KISS, with which the author of this advice does not seem to be fully familiar...

[Robert-ywms]

Passing booleans is a bigger problem in languages that don't support named arguments. Js/ts is the one that immediately comes to mind.

Edit: also it's definitely valid to start with the boolean, evolve to an enum if there are more than 2 options and finally inject the discount as a strategy if that gets too complicated. Refactoring is allowed!

[SteffenSkov]

To uncle Bob's defense I think it is worth remembering where he comes from. Being "a senior" developer myself, I have also been through that period of time where object oriented programming was new enough that everybody were designing class hierarchies so deep that they were reaching hell. People were writing methods several hundreds of lines long. Nobody paid attention to number of arguments for functions/methods.
My impression is that nowadays new developers are learning better OOP skills during their education, and therefor those somewhat extreme measures put forward by uncle Bob seems completely out of place. There are still some valuable points to what he is saying/writing, I think.

[ryankueter]

The context of the code matters. In many instances, automatically using Enums could be over engineering. If it only requires a Boolean, then use that. In many instances, an Enum works well, especially for parameters. Or if something else would work better, then use that. But don't implement unused code features that could lead to confusion, like implementing a base class that contains no functionality, or an Enum where a Boolean value would suffice, or applying a more complex pattern, such as creating a class that returns a true or false value. That advice came from a mid-level developer aspiring to be the teacher instead of continuing to be the student.

[AmateurSpecialist]

I think this might fall under "premature optimization." Granted, in the past, I've converted bools to enums when they magically got a third value, but it's so dang trivial that you should just let the bools be bools until you need them to be anything else.

[Palladin]

With CleanCode, it's not the rules that count, but the fact that we deal with these rules, even if we don't follow them - hopefully after careful consideration.

[vchap]

An enum can provide additional values like GoldDiscount and SilverDiscount. But for business logic that includes orders and pricing, it would make sense to use a strategy pattern instead of conditionals. For simple/POC projects, a boolean is perfectly fine.

[Fnalspace]

We use a lot of booleans for method arguments in our production code and one boolean is not a problem, when it has a good name.
As soon as we have more boolean, regardless of the order - we replace all booleans with an flags enum or better, separate the method into multiple ones, if possible (often this is not possible, due to duplicate code). But there is always a point, where you have to glue them together, so in the end - you don't gain that much by splitting methods.
I personally like booleans in methods or functions and as soon as i have more than one directly following the other one, it is a code-smell and i replace it with an bit-flags enum instead.

[HumanNotFound]

I think it would be better to have a method that calculates the discount and passes the discount into the ProcessOrder method, which always does the discount, even if there is no discount.

[trader]

Project on day one: There are only two types of discount, discount or no discount (booleans are everywhere in the code base, all public API, etc)
Project on day one-hundred: We have currently 673 discount schemes, depending on the customer type, geo location, day of week, phases of the moon...

😆

[kikinobi]

Sometimes you really really just need a simple boolean and you will never have to change it

[TheBunzinator]

I completely agree with you. There are use cases for passing a bool, and there are use cases for calling one func for true and one for false. But either way, there is a conditional somewhere. Unless the situation lends itself to branchless code. Relegate dogma to prioritised options at best.

[PbPomper]

I agree that passing down flags to a method is a definite code smell. If you pass a flag, you probably need two different methods or encapsulate that flag (for example create an Order object and pass that down).

The advice itself isn't even that bad, but the example they show is (like you said).