Funktionen in Kotlin

Wenn du Kotlin für Android lernst, sind Funktionen einer der wichtigsten Bausteine für lesbaren Code. Eine Funktion kapselt eine kleine Aufgabe: Sie bekommt optional Eingaben, verarbeitet sie und gibt optional ein Ergebnis zurück. In echten Android-Projekten nutzt du Funktionen, um Absicht sichtbar zu machen, Duplikate zu vermeiden und Logik so klein zu halten, dass du sie prüfen, debuggen und später ändern kannst.

Was ist das?

Eine Funktion ist ein benannter Block von Code. Statt dieselben Anweisungen mehrfach an verschiedenen Stellen zu schreiben, gibst du dieser Logik einen Namen und rufst sie bei Bedarf auf. In Kotlin beginnt eine Funktion mit dem Schlüsselwort fun. Danach folgen der Funktionsname, eine Parameterliste in Klammern und optional ein Rückgabetyp.

Das mentale Modell ist einfach: Eine Funktion ist wie eine kleine Maschine mit einem klaren Zweck. Parameter sind die Eingaben. Der Rückgabetyp beschreibt, welche Art von Ergebnis herauskommt. Der Funktionskörper enthält die Arbeit, die erledigt wird. Je klarer diese drei Teile sind, desto leichter kannst du Code lesen.

Im Android-Kontext begegnen dir Funktionen überall: in ViewModel-Klassen, in Repositorys, in Mappern zwischen Netzwerk- und UI-Modellen, in Compose-Composables und in kleinen Hilfsfunktionen für Formatierung oder Validierung. Eine gute Funktion beantwortet beim Lesen oft schon durch ihren Namen, warum es sie gibt. calculateTotalPrice() ist verständlicher als drei verstreute Rechenschritte in einem Button-Click-Handler.

Wichtig ist dabei die Größe. Der Roadmap-Schritt hier dreht sich nicht darum, jede Zeile in eine eigene Funktion zu verschieben. Es geht darum, kleine Funktionen zu schreiben, die Absicht klären und Wiederholung senken. Wenn eine Funktion nur technische Details versteckt, aber keinen klaren Begriff in deiner App ausdrückt, bringt sie wenig. Wenn sie dagegen eine Regel deiner App benennt, wird dein Code stabiler.

Wie funktioniert es?

Eine Kotlin-Funktion kann ohne Parameter starten:

fun refresh() {
    // Daten neu laden
}

Sie kann Parameter annehmen:

fun greetUser(name: String): String {
    return "Hallo, $name"
}

Hier ist name ein Parameter vom Typ String. Der Rückgabetyp steht nach dem Doppelpunkt: String. Der Körper nutzt return, um ein Ergebnis zurückzugeben. Für Anfänger ist diese Schreibweise gut, weil sie alle Teile sichtbar macht.

Wenn eine Funktion nichts Sinnvolles zurückgibt, ist ihr Rückgabetyp Unit. Du musst Unit meistens nicht hinschreiben. Eine Funktion wie logScreenOpen() führt eine Aktion aus, liefert aber keinen Wert, mit dem du weiterrechnest. In Android-Code solltest du solche Funktionen bewusst verwenden, weil sie oft Nebenwirkungen haben: Sie ändern Zustand, schreiben Logs, starten Navigation oder lösen einen Ladevorgang aus.

Kotlin erlaubt außerdem Expression-Bodies. Das ist eine kurze Schreibweise für Funktionen, die direkt aus einem Ausdruck bestehen:

fun isValidUserName(name: String): Boolean = name.length >= 3

Hier gibt es keine geschweiften Klammern und kein return. Der Ausdruck rechts vom Gleichheitszeichen ist das Ergebnis. Der Rückgabetyp kann oft weggelassen werden, weil Kotlin ihn ableitet:

fun displayName(firstName: String, lastName: String) = "$firstName $lastName"

Für Lernende ist wichtig: Typableitung ist bequem, aber nicht immer die beste Wahl. Bei öffentlichen Funktionen, Funktionen in größeren Teams oder Funktionen mit fachlicher Bedeutung ist ein expliziter Rückgabetyp oft besser. Er macht die Schnittstelle stabiler und hilft dir beim Code-Review zu erkennen, ob eine Änderung das erwartete Ergebnis verändert.

Parameter sollten genau das ausdrücken, was die Funktion braucht. Zu viele Parameter sind ein Warnsignal. Wenn du vier oder fünf Werte übergibst, prüfe, ob diese Werte eigentlich zusammengehören, etwa in einem Datenobjekt. Auch boolesche Parameter können unklar sein. Ein Aufruf wie loadUser(true) sagt wenig. loadUser(forceRefresh = true) ist deutlich besser, weil benannte Argumente die Absicht zeigen.

In Compose findest du Funktionen in einer besonderen Form: Composables sind ebenfalls Funktionen. Sie beschreiben UI aus Daten. Auch dort gilt: Kleine Funktionen helfen. Eine große Composable-Funktion mit Formatierung, Zustandslogik, Klickverhalten und UI-Struktur wird schnell schwer wartbar. Du solltest aber nicht wahllos aufteilen. Schneide dann eine Funktion heraus, wenn sie einen eigenen Sinn hat, etwa UserNameText(...) oder formatLastLogin(...).

In der Praxis

Stell dir vor, du baust eine Profilansicht. Du bekommst aus einem Repository einen Benutzernamen und einen Zeitpunkt des letzten Logins. In der UI soll ein kurzer Status stehen. Eine schlechte Lösung wäre, diese Formatierung direkt an mehreren Stellen im Compose-Code zu wiederholen. Besser ist eine kleine Funktion mit klaren Parametern und einem klaren Rückgabetyp.

fun buildLoginStatus(userName: String, minutesSinceLogin: Int): String {
    return if (minutesSinceLogin <= 5) {
        "$userName ist gerade aktiv"
    } else {
        "$userName war vor $minutesSinceLogin Minuten aktiv"
    }
}

Diese Funktion ist klein, lesbar und leicht testbar. Sie bekommt zwei Eingaben und gibt einen String zurück. Der Name beschreibt nicht, wie der Text gebaut wird, sondern was das Ergebnis bedeutet: ein Login-Status.

Für eine kurze, reine Berechnung passt auch ein Expression-Body:

fun isRecentlyActive(minutesSinceLogin: Int): Boolean = minutesSinceLogin <= 5

Du könntest diese Funktion in der ersten Funktion verwenden:

fun buildLoginStatus(userName: String, minutesSinceLogin: Int): String =
    if (isRecentlyActive(minutesSinceLogin)) {
        "$userName ist gerade aktiv"
    } else {
        "$userName war vor $minutesSinceLogin Minuten aktiv"
    }

Das ist ein sinnvoller Einsatz, wenn isRecentlyActive eine echte Regel deiner App beschreibt. Wenn die Grenze 5 später geändert wird, liegt die Entscheidung an einer Stelle. Außerdem kannst du diese Regel separat testen.

Ein einfacher Unit-Test könnte so aussehen:

@Test
fun recentLoginReturnsActiveText() {
    val result = buildLoginStatus(
        userName = "Mina",
        minutesSinceLogin = 3
    )

    assertEquals("Mina ist gerade aktiv", result)
}

So prüfst du nicht Compose, nicht Navigation und nicht das Android-Framework, sondern eine kleine fachliche Entscheidung. Genau darin liegt der Wert kleiner Funktionen: Sie trennen reine Logik von Umgebungscode. Das macht Tests schneller und Fehler leichter auffindbar.

Eine praktische Entscheidungsregel lautet: Extrahiere eine Funktion, wenn du einem Codeabschnitt einen besseren Namen geben kannst als den Kommentar, den du sonst darüber schreiben würdest. Statt // prüft, ob Nutzer vor kurzem aktiv war zu schreiben, ist isRecentlyActive(...) meist die bessere Lösung. Ein guter Funktionsname entfernt oft den Bedarf für einen erklärenden Kommentar.

Eine typische Stolperfalle ist die zu allgemeine Hilfsfunktion. Namen wie handleData(), processInput() oder doStuff() helfen kaum. Sie verstecken Code, erklären aber keine Absicht. Ebenso problematisch sind Funktionen, die zu viel tun: Daten laden, Fehler behandeln, UI-Status ändern und Analytics senden. Solche Funktionen sind schwer zu testen, weil du viele Dinge gleichzeitig prüfen musst.

Achte auch auf Rückgabetypen. Wenn eine Funktion eigentlich eine Entscheidung berechnet, sollte sie einen Wert zurückgeben, zum Beispiel Boolean, String oder ein eigenes Datenobjekt. Wenn sie stattdessen direkt UI-Zustand ändert, wird sie schwerer wiederverwendbar. In Android-Architektur ist das besonders wichtig: Ein ViewModel sollte UI-Zustand aus Daten ableiten können. Kleine Funktionen mit klaren Rückgabetypen helfen dir, diese Ableitung nachvollziehbar zu halten.

Expression-Bodies sind nützlich, aber nicht für jeden Fall. Nutze sie für kurze, gut lesbare Ausdrücke. Wenn du mehrere Zwischenschritte, Fehlerfälle oder erklärende Variablen brauchst, ist ein normaler Funktionskörper oft besser. Lesbarkeit ist wichtiger als Kürze. Ein einzeiliger Ausdruck, den du zweimal lesen musst, ist kein Gewinn.

Im Code-Review kannst du Funktionen mit drei Fragen prüfen: Versteht man am Namen, warum die Funktion existiert? Sind die Parameter vollständig, aber nicht überladen? Passt der Rückgabetyp zur Aufgabe? Wenn du diese Fragen sauber beantworten kannst, ist die Funktion meist auf einem guten Weg.

Fazit

Funktionen sind in Kotlin mehr als eine syntaktische Pflichtübung. Sie sind dein Werkzeug, um Android-Code in verständliche, prüfbare Einheiten zu schneiden. Übe das an einer bestehenden Klasse: Suche eine doppelte Berechnung oder eine unklare Bedingung, extrahiere eine kleine Funktion mit passenden Parametern und bewusstem Rückgabetyp, schreibe einen kleinen Test dafür und lies den Aufruf danach wie einen Satz. Wenn der Code dadurch klarer wird, hast du den Kern dieses Roadmap-Schritts verstanden.