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

Summary

In this episode of 'Code Cop,' the host critiques a popular piece of coding advice that suggests replacing Boolean parameters with enums in methods. While acknowledging the concept of 'Boolean blindness' in code, the host explains that the given example and justification for using enums are flawed. They argue that using enums in such a case does not improve performance or readability, and in some situations, keeping Booleans is perfectly fine. The host emphasizes the importance of context over dogmatic adherence to clean code principles and encourages a nuanced discussion.

Takeaways

• 😀 The video critiques bad advice often found on platforms like LinkedIn, Twitter, or blogs and aims to turn that advice into useful lessons.
• 😅 The advice discussed today suggests replacing booleans as method parameters with enums, which the creator disagrees with.
• 🤔 The host acknowledges that using booleans as parameters can sometimes be problematic but disagrees with the example and justification given.
• 🧐 The advice suggests using an enum (e.g., 'DiscountOption' with 'None' or 'ApplyDiscount') instead of a boolean like 'applyDiscount', but the host argues this doesn't solve any real problem.
• 😠 The presenter believes that enums do not provide a performance improvement over booleans, and the example given in the blog post is redundant.
• 🤷 The presenter highlights that a properly named boolean parameter like 'applyDiscount' is clear and doesn’t suffer from the ambiguity that the blog post suggests.
• 😂 The presenter mocks the idea that replacing booleans with enums simplifies debugging or reduces maintenance costs, considering it overcomplicates the issue.
• 😡 The video critiques the 'Clean Code' principle that suggests avoiding booleans in methods, labeling it as overly dogmatic and impractical in many scenarios.
• 🤓 The presenter suggests splitting methods based on boolean values only when the method performs two entirely different actions, but doesn't agree with always doing so.
• 🤔 The host encourages the audience to share their opinions on this topic, sparking further discussion and debate about the best practices for handling booleans in code.

Q & A

What is the main topic of the video?

The main topic of the video is a critique of bad coding advice found on platforms like LinkedIn and blogs, specifically focusing on the recommendation to replace Boolean parameters in methods with enums.

What is Boolean blindness?

Boolean blindness refers to the tendency of developers to overlook the implications of using Boolean values, particularly in conditionals, method returns, and data storage. It can lead to code that is harder to read, maintain, or debug.

What is the specific advice the speaker critiques in this episode?

The speaker critiques the advice suggesting that developers should avoid using Boolean values as method parameters and instead use enums to represent two states, such as 'None' and 'ApplyDiscount'.

Why does the speaker think the example of using enums instead of Booleans is bad?

The speaker argues that replacing a Boolean with an enum in this case doesn’t solve any significant issues. It maintains the same performance and logic as the original Boolean solution. The speaker also believes the justification given for using enums is flawed and doesn’t improve code readability or maintainability.

What is the performance argument related to using enums vs. Booleans?

The speaker notes that both Booleans and enums are value types in C#, meaning they don’t impact performance in terms of allocation. Using an enum instead of a Boolean does not provide any performance advantages in this context.

What does the speaker mean by ‘named parameters’ in the context of this example?

The speaker refers to 'named parameters' in a method call, where the Boolean parameter 'applyDiscount' is explicitly set to 'True'. This makes the code more readable and clear by explicitly showing the meaning of the Boolean value in the method call.

What are some valid cases for avoiding Booleans as method parameters, according to the speaker?

The speaker acknowledges that Booleans can be problematic when they cause a method to perform two completely different actions based on the Boolean value. In such cases, it may be better to split the method into two separate methods, each with a clearer purpose.

Why does the speaker think the ‘clean code’ advice is too dogmatic?

The speaker believes that the 'clean code' advice, which discourages passing Booleans into methods, is overly rigid and doesn’t apply to the majority of cases. The speaker argues that while there are cases where it makes sense to avoid Booleans, many scenarios don’t require splitting methods and can use Booleans effectively.

What criticism does the speaker have regarding ‘clean code’ principles?

The speaker criticizes 'clean code' principles for being overly strict and sometimes impractical, arguing that they often lead to unnecessarily complex or duplicated code, rather than improving clarity or maintainability.

What does the speaker suggest as a better approach when dealing with Booleans in methods?

The speaker suggests that instead of blindly following rules like 'never use Booleans', developers should evaluate the specific context. If a Boolean parameter makes sense and doesn’t introduce ambiguity, it should be used. If it leads to separate actions, then splitting the method may be a better solution.