Kotlin Code Review: What Annoys Senior Developers

How Seniors See Your Kotlin Code: Analysis with Real Examples

You wrote the code, pushed it to the repository, and are nervously waiting for approval. But instead of a green checkmark, a dozen comments from a senior developer arrive. Sound familiar? If you write in Kotlin, you've probably encountered a situation where your seemingly perfect code turns into a pumpkin after code review.

In this article, we'll look at which typical senior developer comments are most often encountered during Kotlin code review. We won't teach you syntax — we'll show you how to write code that passes review on the first try. Let's go!

1. Null Safety: "Why aren't you using the Elvis operator?"

One of Kotlin's main features is null safety. But many developers, especially those coming from Java, continue to write code in a "check-for-null-and-execute" style. Seniors notice this immediately.

Bad Example (Java-style)

fun getUserName(user: User?): String {\n    return if (user != null) {\n        user.name\n    } else {\n        "Unknown"\n    }\n}

Good Example (Kotlin-style)

fun getUserName(user: User?): String {\n    return user?.name ?: "Unknown"\n}

Using the Elvis operator (?:) and safe call (?.) makes the code concise and readable. Seniors love it when you save lines without losing clarity. Remember: if (x != null) { ... } else { ... } is bad practice.

2. Extension Functions: "Where are your utilities?"

When you see a static utility class like StringUtils.capitalize(str), an experienced Kotlin developer will wince. Extension functions are what make Kotlin so elegant.

Bad Example

object StringUtils {\n    fun capitalize(text: String): String {\n        return text.replaceFirstChar { it.uppercase() }\n    }\n}\n\n// Usage\nval result = StringUtils.capitalize("hello")

Good Example

fun String.capitalizeFirst(): String {\n    return this.replaceFirstChar { it.uppercase() }\n}\n\n// Usage\nval result = "hello".capitalizeFirst()

Seniors will say: "Why are you creating a junk object? Just extend the class!" Use extension functions — it improves readability and follows Kotlin best practices.

3. Sealed Classes Instead of Enum: "Your enum is outdated"

Enums in Kotlin are good, but sealed classes offer much more flexibility. Especially when you need to store different data types in the same hierarchy.

Bad Example (enum)

enum class Result {\n    SUCCESS,\n    ERROR,\n    LOADING\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        Result.SUCCESS -> // ...\n        Result.ERROR -> // ...\n        Result.LOADING -> // ...\n    }\n}

Good Example (sealed class)

sealed class Result {\n    data class Success(val data: List<Item>) : Result()\n    data class Error(val message: String, val code: Int) : Result()\n    object Loading : Result()\n}\n\nfun handleResult(result: Result) {\n    when (result) {\n        is Result.Success -> println("Data: ${result.data}")\n        is Result.Error -> println("Error: ${result.message}")\n        Result.Loading -> println("Loading...")\n    }\n}

Senior developers will appreciate that you use sealed classes to represent states. This is one of the main senior kotlin tips — make type hierarchies explicit.

4. Scope Functions: "You forgot about let, apply, and run"

Scope functions (let, apply, run, with, also) are powerful