Code review in Kotlin: what to check and how to give feedback

Code review in Kotlin: what to check and how to give feedback

Code review is not just a formality or a way to find bugs. It is a crucial process for knowledge sharing and improving code quality. In Kotlin, with its expressive syntax and powerful features, reviewing requires special attention to detail. In this article, we will break down what to look for when reviewing Kotlin code and how to give feedback that is helpful, not hurtful.

1. What to check: a checklist for Kotlin developers

When starting a review, don't try to cover everything at once. It's better to go through key categories. Here is a structured checklist for Kotlin.

1.1. Null Safety and working with nullable types

Kotlin solves the NPE problem, but only if the developer doesn't overuse !! (not-null assertion). This is a major red flag.

\n
• What to look for: Use of !! in production code. It can almost always be replaced with ?.let, ?: (elvis), or a safe cast as?.
\n
• Example of bad code:
\n

fun processUser(user: User?) {\n    val name = user!!.name // Potential NPE!\n    println(name)\n}

\n
• Example of good code:
\n

fun processUser(user: User?) {\n    user?.let { safeUser ->\n        println(safeUser.name)\n    } ?: run {\n        println("User is null")\n    }\n}

1.2. Using collections and Stream API

Kotlin offers a rich set of functions for working with collections. Check how efficiently and readably they are used.

\n
• What to look for: Unnecessary for loops where map, filter, groupBy could be used. Also, mutable collections (MutableList) if immutable ones (List) would suffice.
\n
• Example of bad code:
\n

val names = mutableListOf<String>()\nfor (item in items) {\n    if (item.isActive) {\n        names.add(item.name)\n    }\n}

\n
• Example of good code:
\n

val names = items\n    .filter { it.isActive }\n    .map { it.name } // Immutable list

1.3. Extension functions and scope

Extension functions are a powerful tool, but they can easily be "smeared" across the project. Check whether their use is appropriate.

\n
• What to look for: Extension functions that change the state of an object (especially if it's not obvious). Functions that should be class methods but are extracted as extensions for "aesthetics".
\n
• Question for the author: "Why is this an extension and not a method of the User class?"
\n

1.4. Using when instead of if-else

Kotlin encourages using when as a more readable alternative to long chains of if-else.

\n
• What to look for: Ladders of if-else with 3+ conditions. These should be replaced with when.
\n

// Instead of this:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// Better like this:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. How to give feedback: from criticism to collaboration

The technical part is only half the battle. The other half is communication. Bad feedback can demotivate a team. Good feedback can build trust.

2.1. The "Why, not What" rule

Instead of simply saying "This is bad," explain why it's bad and how to fix it.

\n
• Bad: "Here !! — redo it