Code-Review in Kotlin: Was Senior-Entwickler nervt

Wie Seniors Ihren Kotlin-Code sehen: Analyse anhand realer Beispiele

Sie haben Code geschrieben, in das Repository gepusht und warten mit angehaltenem Atem auf die Freigabe. Doch statt des grünen Hakens erhalten Sie ein Dutzend Kommentare vom Senior-Entwickler. Kommt Ihnen das bekannt vor? Wenn Sie in Kotlin programmieren, sind Sie sicherlich schon in die Situation geraten, dass Ihr scheinbar perfekter Code nach einem Code-Review zum Kürbiss wird.

In diesem Artikel analysieren wir, welche typischen Anmerkungen von Seniors am häufigsten bei Code-Reviews in Kotlin vorkommen. Wir werden Ihnen nicht die Syntax beibringen – wir zeigen Ihnen, wie Sie so schreiben, dass Ihr Code beim ersten Mal durch das Review kommt. Los geht's!

1. Null Safety: „Warum verwendest du nicht den Elvis-Operator?“

Eine der Hauptfunktionen von Kotlin ist die Null Safety. Aber viele Entwickler, insbesondere diejenigen, die von Java kommen, schreiben weiterhin Code im Stil „prüfe-auf-null-und-führe-aus“. Seniors sehen das sofort.

Schlechtes Beispiel (Java-Stil)

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

Gutes Beispiel (Kotlin-Stil)

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

Die Verwendung des Elvis-Operators (?:) und des Safe Calls (?.) macht den Code prägnant und lesbar. Seniors lieben es, wenn Sie Zeilen sparen, ohne an Klarheit zu verlieren. Merken Sie sich: if (x != null) { ... } else { ... } ist ein No-Go.

2. Extension Functions: „Wo sind deine Utilities?“

Wenn Sie eine statische Utility-Klasse im Stil von StringUtils.capitalize(str) sehen, wird ein erfahrener Kotlin-Entwickler das Gesicht verziehen. Extension Functions sind das, was Kotlin so elegant macht.

Schlechtes Beispiel

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

Gutes Beispiel

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

Seniors werden sagen: „Warum erstellst du ein Müll-Objekt? Erweitere einfach die Klasse!“ Verwenden Sie Extension Functions – das verbessert die Lesbarkeit und folgt den Kotlin Best Practices.

3. Sealed Classes statt Enum: „Dein Enum ist veraltet“

Enums in Kotlin sind gut, aber Sealed Classes bieten wesentlich mehr Flexibilität. Besonders dann, wenn verschiedene Datentypen in einer Hierarchie gespeichert werden müssen.

Schlechtes Beispiel (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}

Gutes Beispiel (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-Entwickler werden es zu schätzen wissen, dass Sie Sealed Classes zur Darstellung von Zuständen verwenden. Dies ist einer der wichtigsten Tipps von Senior Kotlin – machen Sie Typhierarchien explizit.

4. Scope Functions: „Du hast let, apply und run vergessen“

Scope Functions (let, apply, run, with, also) sind mächtig