Code Review in Kotlin: Was man prüfen sollte und wie man Anfängern Feedback gibt

Code Review in Kotlin: Was man prüfen sollte und wie man Anfängern Feedback gibt

Code Review ist einer der Schlüsselprozesse in der modernen Softwareentwicklung. Für Anfänger in Kotlin wirkt es oft einschüchternd: Wie findet man Fehler? Worauf genau sollte man achten? Wie verletzt man den Autor des Codes nicht? In diesem Artikel gehen wir darauf ein, worauf man bei Code Reviews von Kotlin-Projekten achten sollte und wie man Feedback gibt, das hilfreich und nicht verletzend ist. Das Material eignet sich sowohl für diejenigen, die gerade erst das Reviewen lernen, als auch für diejenigen, die ihre Fähigkeiten verbessern möchten.

Warum ist Code Review in Kotlin wichtig?

Kotlin ist eine moderne, prägnante und sichere Sprache, die dem Entwickler jedoch viel Freiheit lässt. Ohne Code Review können leicht Fehler in Bezug auf Null-Sicherheit, falsche Verwendung von Coroutinen oder übermäßige Komplexität auftreten. Reviews helfen:

• Bugs frühzeitig zu finden.
• Die Lesbarkeit und Wartbarkeit des Codes zu verbessern.
• Wissen innerhalb des Teams zu verbreiten.
• Einen einheitlichen Codestil einzuhalten.

Für Anfänger ist es auch eine hervorragende Möglichkeit, anhand von Beispielen anderer zu lernen. Kommen wir nun zu den Details.

Was man beim Code Review von Kotlin-Code prüfen sollte

Hier ist eine Checkliste mit den wichtigsten Punkten, die Sie in jedem Pull Request überprüfen sollten. Unterteilen wir sie in logische Blöcke.

1. Null-Sicherheit und Typen

Kotlin ist stolz auf seine Null-Sicherheit, aber diese kann verletzt werden. Prüfen Sie:

• Werden nullable Typen (z. B. String?) nur dort verwendet, wo es wirklich nötig ist?
• Gibt es unnötige !! (non-null assertion)? Idealerweise sollten sie im Production-Code gar nicht vorkommen.
• Werden sichere Aufrufe (?.let { ... }) und der Elvis-Operator (?:) anstelle von if (x != null) verwendet?

Schlechtes Beispiel:

val name: String? = getName()val length = name!!.length // Gefährlich: löst NPE aus, wenn name == null

Gutes Beispiel:

val name: String? = getName()val length = name?.length ?: 0 // Sicher: wenn null, dann 0

2. Funktionen und ihre Signaturen

Kotlin unterstützt benannte Argumente und Standardwerte. Prüfen Sie:

• Ist die Funktion zu lang (mehr als 20–30 Zeilen)? Vielleicht sollte sie aufgeteilt werden.
• Werden Standardparameter verwendet, um den Aufruf zu vereinfachen?
• Gibt es Funktionen mit mehr als 3–4 Parametern? Das erschwert das Lesen.
• Ist die Verwendung von Extension-Funktionen angemessen? Sie sollten den Zustand des Objekts nicht ändern.

Beispiel:

// Stattdessen:fun processUserData(name: String, age: Int, email: String, city: String, phone: String) { ... }

// Besser so:data class UserData(val name: String, val age: Int, val email: String, val city: String, val phone: String)fun processUserData(user: UserData) { ... }

3. Arbeit mit Coroutinen

Coroutinen sind ein mächtiges Werkzeug in Kotlin, aber sie können leicht falsch verwendet werden. Achten Sie auf:

• Wird der Thread innerhalb einer Coroutine blockiert (Aufruf von Thread.sleep() oder blockierende Ein-/Ausgabe)?
• Wird der richtige Dispatcher verwendet (Dispatchers.IO für Netzwerkanfragen, Dispatchers.Main für die UI)?
• Gibt es Coroutine-Leaks (z. B. in einer Activity gestartet ohne Abbruch)?
• Wird withContext zum Wechseln des Dispatchers verwendet, anstatt launch innerhalb von launch?

Schlechtes Beispiel:

fun fetchData() {    GlobalScope.launch { // Leak: wird nicht abgebrochen, wenn die Komponente zerstört wird        Thread.sleep(1000) // Blockiert den Thread!    }}

Gutes Beispiel:

fun fetchData(scope: CoroutineScope) {    scope.launch {        withContext(Dispatchers