While it seems ideal to never have null in your code, it’s not always possible to avoid, and sometimes shouldn’t be avoided. Whether it is a REST API, or an Android System Service, representing data that may not be available as a nullable type is important because it allows us to create code paths to handle both cases. When operating in a non-hermetic environment, we run into cases where some data sources are not reliable and may provide null content. In Kotlin, nullability is intentionally treated to achieve null safety. If you need a way to represent whether a value is available or unavailable, then null is appropriate in this case as well.Īpps must consume external data sources that we don’t have full control over. If you need a way to represent whether a value is initialized or whether it has no value, then null is appropriate in this case. Valid usages of null in Kotlin 1) When Representing “No Value” var user: User? = null

There are perfectly appropriate safe uses of null in Kotlin. However, just because it’s easy to identify null in Kotlin doesn’t mean we should use it everywhere. Yes, it’s to be avoided in most code, but in Kotlin, null is part of the type system and the compiler will tell you when you haven’t handled it appropriately. I was recently reviewing code with a developer that is learning Kotlin and they were adamant that:

Kotlin is not null