Kotlin Code Smell 10 - Null
Embracing Existence: Say No to Null

I've started to work as a software engineer at 2014, however, I started to write code at high-school.
My first language was Assembly, but still, I fall in love with the possibilities to make the computer to do as you wish, shortly after that I started to write in C.
Later on I studied a practical engineering in electricity, and during this time discovered that I preferred much more writing code than design electrical components.
As a result of this understanding I decided to switch and study bachelor degree in computer science in Reichman university, where the focus was of the Java language.
Today I'm working at SumUp using Kotlin, SpringBoot & Micronaut, Cassandra and Kafka
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/whenstatements.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
nulldoes 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
nullis 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.




