Kotlin Boolean? in if: How Not to Lose Performance

Kotlin Boolean? in if: How Not to Lose Performance and Your Sanity

Have you ever written code in Kotlin and suddenly frozen in front of a simple if? Not because you don't know what to write, but because you're facing a Boolean? — a nullable boolean value. And instantly a hundred questions pop into your head: "What if it's null? How will this affect performance? Won't the app crash?"

Sound familiar? Don't worry, you're not alone. The question "Use of Boolean? in if expression" on Stack Overflow has gathered thousands of views. And this is no coincidence: nullable types are one of Kotlin's main features, but using them incorrectly can lead to headaches and performance loss.

In this article, we'll break down how to work correctly with Boolean? in conditional statements, what pitfalls exist, and how to write code that is not only safe but also fast. Let's go!

What is Boolean? and Why Is It Even a Problem?

First, let's recall that Boolean? in Kotlin is the nullable version of a regular Boolean. It can take three values: true, false, and null. It seems like just one extra value, but oh, the trouble it brings!

The problem arises when you try to use Boolean? directly in an if:

val isActive: Boolean? = null

// Compilation error!if (isActive) {    println("Active")}

Kotlin won't let you do that. And that's correct! Because null in the context of boolean logic is uncertainty. The compiler is literally screaming: "Hey, what should I do if it's null? I'm not a mind reader!"

Three Ways to Handle Boolean? in if

Let's look at the main approaches developers use. Each has its pros and cons, especially from a performance perspective.

1. Explicit Null Check (Safest)

val isActive: Boolean? = someFunction()

if (isActive == true) {    println("Active")} else if (isActive == false) {    println("Inactive")} else {    println("Status undefined")}

This approach is the most readable and safe. You explicitly handle all three states. But there's a nuance: if you only need to check for true, and handle null and false the same way, the code becomes redundant.

2. Elvis Operator ?: (Concise but Dangerous)

val isActive: Boolean? = someFunction()

if (isActive ?: false) {    println("Active or null treated as false")}

Elegant, right? The ?: (Elvis) operator provides a default value if the left side is null. But there's a hidden problem here: you lose information about whether the value was null. For business logic, this can be critical.

3. The let() Function (Functional Style)

val isActive: Boolean? = someFunction()

isActive?.let { value ->    if (value) {        println("Active")    }}

Here, let executes only if isActive is not null. The code looks nice, but it creates an extra lambda. For high-load areas, this can be suboptimal.

Performance: Myths and Reality

Now for the interesting part — how different approaches affect execution speed. We conducted a small study (yes, right here at PythonLib we love experiments!).

What Happens Under the Hood?

Let's look at the bytecode for different options. Let's take a simple example:

// Option 1: explicit checkif (isActive == true) { ... }

// Option 2: Elvis operatorif (isActive ?: false) { ... }

In the first case, Kotlin generates roughly this bytecode:

// Pseudocodeif (isAc