Skip to main content

Command Palette

Search for a command to run...

Kotlin Code Smell 10 - Null

Embracing Existence: Say No to Null

Published
2 min read
Kotlin Code Smell 10 - Null

TL;DR: Null does not exist in the real world. Its creator regrets it, and programmers worldwide suffer from it. Avoid being a part of it.

Programmers often use null to represent various conditions such as absence, undefined values, or errors. However, this leads to coupling and errors due to multiple interpretations.

Problems

  • Coupling between callers and senders.

  • Mismatch between callers and senders.

  • Pollution with if/when statements.

  • Null is not polymorphic with real objects, resulting in Null Pointer Exceptions.

  • Null does not exist in the real world, violating the Bijection Principle.

Solutions

  • Avoid using nullable types whenever possible.

  • Use the NullObject pattern to eliminate conditional statements.

Exceptions

  • APIs, databases, and external systems where null does exist.

Sample Code

Wrong

class CartItem(val price: Double)

class DiscountCoupon(val rate: Double)

class Cart(
    private val items: List<CartItem>,
    private val discountCoupon: DiscountCoupon?
) {
    fun subtotal() = 
        items
            .fold(0.0) { acc, next -> acc + next.price }
    fun total() =
        discountCoupon
            ?.let {
                subtotal() * (1 - discountCoupon.rate)
            } ?: subtotal()
}

fun main() {
    val cartItems = listOf(
        CartItem(1.0),
        CartItem(2.0),
        CartItem(7.0)
    )

    var cart = Cart(cartItems, DiscountCoupon(0.15))
    println(cart.total()) // 10 - 1.5 = 8.5

    cart = Cart(cartItems, null);
    println(cart.total()) // 10 - null  = 10
}

Right

class CartItem(val price: Double)

interface Coupon {
    fun discount(subtotal: Double): Double
}

class DiscountCoupon(private val rate: Double) : Coupon {
    override fun discount(subtotal: Double) = subtotal * (1 - rate)
}

class NullCoupon : Coupon {
    override fun discount(subtotal: Double) = subtotal
}

// Notice that we're not using a nullable type for Coupon anymore!
class Cart(
    private val items: List<CartItem>,
    private val discountCoupon: Coupon
) {
    fun subtotal() =
        items
            .fold(0.0) { acc, next -> acc + next.price }
    fun total() = discountCoupon.discount(subtotal())
}

fun main() {
    val cartItems = listOf(
        CartItem(1.0),
        CartItem(2.0),
        CartItem(7.0)
    )

    var cart = Cart(cartItems, DiscountCoupon(0.15))
    println(cart.total()) // 10 - 1.5 = 8.5

    cart = Cart(cartItems, NullCoupon())
    println(cart.total()) // 10 - nullObject  = 10
}

Conclusion

  • null is often considered a billion-dollar mistake. Despite that, many programming languages support its usage, and libraries even encourage it. In Kotlin, it's recommended to avoid nullable types unless absolutely necessary, and if needed, utilize the NullObject pattern to represent the absence of a field.

More info

Credits

Kotlin Code Smells

Part 27 of 36

In this series, we will see several symptoms and situations that make us doubt the quality of our development. We will present possible solutions. Most are just clues. They are no hard rules.

Up next

Kotlin Code Smell 9 - Subclassification for Code Reuse

Crafting Flexible Code: The Power of Composition Over Inheritance

More from this blog

Yonatan Karp-Rudin | kotlin for backend developer skills | java for backend developer skills | SpringBoot | Tutorials

57 posts

Experienced Senior Software Engineer passionate about functional programming & Kotlin. Excels in app development, optimization, and team collaboration. Let's create something amazing!