Writing Better Kotlin Code — Real-World Scenarios

Now, let’s apply our newfound wisdom to real-world scenarios. We’ll transform the previously discussed bad practices into best practices with examples that are common in advanced Kotlin development.

A) Enhanced Nullability Handling

Scenario: You’re working on a user profile feature and need to handle potentially null values in a user object.

Bad Practice:

val city = user?.address?.city?.let { it } ?: "Unknown"

Better Approach:

val city = user?.address?.city ?: "Unknown"

Explanation: By removing redundant let and using the Elvis operator (?:), the code becomes more concise and readable. It also efficiently handles the null case.

Let’s look at another scenario:

Developing a function in a financial application that applies a discount only if the order amount exceeds a certain threshold.

Usual Practice: Verbose conditional checks with nullable types:

val discount = if (order != null && order.amount > 100) order.calculateDiscount() else null

Better Approach: Using takeIf to succinctly apply the condition:

val discount = order?.takeIf { it.amount > 100 }?.calculateDiscount()

Explanation: The takeIf function here elegantly handles the condition, making the code more readable. It checks if the order’s amount is greater than 100; if so, calculateDiscount() is called, otherwise, it returns null. This use of takeIf encapsulates the condition within a concise, readable expression, showcasing Kotlin’s prowess in writing clear and efficient conditional logic.

B) Optimizing Collection Operations

Scenario: Filtering and transforming a large list of products.

Bad Practice:

val discountedProducts = products.filter { it.isOnSale }.map { it.applyDiscount() }

Better Approach:

val discountedProducts = products.asSequence()
                                 .filter { it.isOnSale }
                                 .map { it.applyDiscount() }
                                 .toList()

Explanation: Using sequences (asSequence) for chain operations on collections improves performance, especially for large datasets, by creating a single pipeline.

C) Refactoring Overcomplicated Expressions

Practice: Credits (Phat Voong)

fun calculateMetric(): Metric {
    return data.A().B().C().D()
    // Unless A, B, C, D all make sense while chaining together 
    // Otherwise you might want to consider the approach suggested below
}

Better Approach (Depends on use case):

fun calculateMetric(): Metric {
    val initial = data.first()
    val transformed = initial.transform()
    val aggregated = transformed.aggregate()
    return aggregated.finalize()
}

Explanation: Breaking down the complex one-liner into multiple steps enhances readability and maintainability, making each step clear and manageable.

D) Updating Shared Resources

Scenario: Implementing thread-safe access to a shared data structure in a multi-threaded environment.

Bad Practice:

var sharedList = mutableListOf<String>()

fun addToList(item: String) {
    sharedList.add(item) // Prone to concurrent modification errors
}

Better Approach: Using Mutex from Kotlin’s coroutines library to safely control access to the shared resource.

val mutex = Mutex()
var sharedResource: Int = 0

suspend fun safeIncrement() {
    mutex.withLock {
        sharedResource++  // Safe modification with Mutex
    }
}

Edited — Answer updated based on 

Xoangon

’s comment. CoroutineScope::actor has been marked as obsolete and it does not mention anything about synchronization.

E) Over Complicating Type-Safe Builders

Bad Practice: Creating an overly complex DSL for configuring a simple object.

class Configuration {
    fun database(block: DatabaseConfig.() -> Unit) { ... }
    fun network(block: NetworkConfig.() -> Unit) { ... }
    // More nested configurations
}

// Usage
val config = Configuration().apply {
    database {
        username = "user"
        password = "pass"
        // More nested settings
    }
    network {
        timeout = 30
        // More nested settings
    }
}

Pitfall: The DSL is unnecessarily verbose for simple configuration tasks, making it harder to read and maintain.

Solution: Simplify the DSL or use a straightforward approach like data classes for configurations.

data class DatabaseConfig(val username: String, val password: String)
data class NetworkConfig(val timeout: Int)

val dbConfig = DatabaseConfig(username = "user", password = "pass")
val netConfig = NetworkConfig(timeout = 30)

Explanation: This approach makes the configuration clear, concise, and maintainable, avoiding the complexity of a deep DSL.

F) Misusing Delegation and Properties

Bad Practice: Incorrect use of by lazy for a property that needs to be recalculated.

val userProfile: Profile by lazy { fetchProfile() }
fun updateProfile() { /* userProfile should be recalculated */ }

Pitfall: The userProfile remains the same even after updateProfile is called, leading to outdated data being used.

Solution: Implement a custom getter or a different state management strategy.

private var _userProfile: Profile? = null
val userProfile: Profile
    get() = _userProfile ?: fetchProfile().also { _userProfile = it }
fun updateProfile() { _userProfile = null /* Invalidate the cache */ }

Explanation: This approach allows userProfile to be recalculated when needed, ensuring that the data remains up-to-date.

G) Inefficient Use of Inline Functions and Reified Type Parameters

Bad Practice: Indiscriminate use of inline for a large function.

inline fun <reified T> processLargeData(data: List<Any>, noinline transform: (T) -> Unit) {
    data.filterIsInstance<T>().forEach(transform)
}

Pitfall: Inlining a large function can lead to increased bytecode size and can impact performance.

Solution: Use inline selectively, especially for small, performance-critical functions.

inline fun <reified T> filterByType(data: List<Any>, noinline action: (T) -> Unit) {
    data.filterIsInstance<T>().forEach(action)
}

Explanation: Restricting inline to smaller functions or critical sections of code prevents code bloat and maintains performance.

H) Overusing Reflection