Android-Kotlin-Style

Android-Kotlin-Style beschreibt, wie du Kotlin-Code in Android-Projekten so schreibst, dass er zu den Erwartungen der Plattform, zu Jetpack-Bibliotheken und zu professioneller Teamarbeit passt. Es geht nicht nur um Einrückung oder Leerzeilen, sondern um eine gemeinsame Sprache im Code: klare Namen, kleine Funktionen, idiomatisches Kotlin, stabile Struktur und ein Stil, der Reviews, Tests und Wartung erleichtert.

Was ist das?

Android-Kotlin-Style ist die praktische Verbindung aus Kotlin-Konventionen, Google-Style-Erwartungen und Android-spezifischen Mustern. Kotlin bringt eigene Sprachideen mit: Null-Sicherheit, Properties, Extension Functions, Lambdas, data class, sealed Typen und Coroutines. Android bringt dazu eigene Rahmenbedingungen: Lebenszyklen, Ressourcen, UI-Zustand, Compose, ViewModels, Tests, Build-Varianten und Release-Qualität. Stil bedeutet, diese beiden Welten so zusammenzuführen, dass dein Code nicht zufällig funktioniert, sondern verlässlich gelesen, geprüft und verändert werden kann.

Ein Anfänger denkt bei Stil oft zuerst an Formatierung. Das ist ein Teil davon, aber nicht der Kern. Das mentale Modell sollte sein: Stil ist ein Vertrag zwischen dir, deinem zukünftigen Ich und deinem Team. Wenn alle Dateien ähnlich aufgebaut sind, musst du beim Lesen weniger raten. Du erkennst schneller, wo Zustand entsteht, wo UI gerendert wird, wo Nebenwirkungen passieren und wo fachliche Regeln stehen. Das spart Zeit in jedem echten Android-Projekt.

Google-Style heißt dabei nicht, dass jede Entscheidung auswendig gelernt werden muss. Wichtiger ist, dass du Code schreibst, der mit den üblichen Android-Werkzeugen harmoniert: Android Studio, Kotlin-Compiler, Lint, Tests, Continuous Integration und Code-Review. Ein einheitlicher Stil hilft auch bei Qualität. Fehler werden nicht automatisch verhindert, aber sie werden sichtbarer. Wenn eine Funktion plötzlich sehr lang ist, wenn ein Composable zu viele Aufgaben übernimmt oder wenn ein Name nicht mehr zur Verantwortung passt, fällt das in einem konsistenten Projekt schneller auf.

Wie funktioniert es?

Android-Kotlin-Style funktioniert durch wiederholbare Entscheidungen. Du entscheidest nicht in jeder Datei neu, wie du Klassen benennst, wie du Zustände modellierst oder wie du Fehler behandelst. Du folgst Konventionen, damit der Code berechenbar bleibt.

Bei Namen gilt: Benenne nach Verantwortung, nicht nach technischer Laune. Eine Klasse LoginViewModel beschreibt klar ihren Platz. Eine Funktion submitLogin() sagt mehr als doAction(). Für Compose sind sprechende Composable-Namen wichtig, meist als Substantiv oder UI-Element: LoginScreen, LoginForm, PasswordField. Mutable State sollte nicht unnötig nach außen gelangen. Wenn dein ViewModel intern einen MutableStateFlow nutzt, veröffentlichst du nach außen typischerweise einen unveränderlichen StateFlow.

Bei Struktur gilt: Trenne UI, Zustand und Logik so, dass jede Ebene testbar bleibt. Ein Composable sollte UI darstellen und Events nach oben melden. Ein ViewModel koordiniert Zustand und Anwendungslogik. Repository- oder Datenquellen-Schichten kümmern sich um Daten. Der Stil zeigt sich darin, wie konsequent du diese Grenzen hältst. Wenn du Netzwerklogik direkt in ein Composable schreibst, ist das nicht nur ein Architekturproblem, sondern auch ein Stilbruch: Der Code ist schwerer zu lesen, schwerer zu testen und schwerer zu ändern.

Bei Kotlin selbst ist idiomatischer Code wichtig. Nutze val, wenn sich ein Wert nicht ändern muss. Nutze Nullable-Typen bewusst statt späterer Überraschungen. Verwende when, sealed interface oder sealed class, wenn du begrenzte Zustände ausdrücken willst. Schreibe nicht Java in Kotlin-Syntax. Ein häufiger Junior-Fehler ist, überall mutable Listen, spät initialisierte Properties oder unnötige Null-Prüfungen zu verwenden, obwohl Kotlin bessere Ausdrucksmittel bietet.

Formatierung gehört trotzdem dazu. Einheitliche Einrückung, sinnvolle Zeilenumbrüche und konsistente Imports senken die Lesekosten. Android Studio kann vieles automatisch formatieren. Trotzdem bleibt Verantwortung bei dir: Ein automatisch formatierter, aber schlecht geschnittener 120-Zeilen-Block ist immer noch schlechter Code. Stil ist also Format plus Design im Kleinen.

Für Tests und CI ist Stil ebenfalls relevant. Gut benannte Funktionen sind leichter testbar, klare Zustandsmodelle erzeugen bessere Testfälle, und konsistente Modulgrenzen erleichtern automatisierte Prüfungen. Wenn dein Projekt in der Continuous Integration formatiert, lintet und testet, wird Stil nicht nur als Teamwunsch behandelt, sondern als Teil des Qualitätsprozesses.

In der Praxis

Stell dir einen einfachen Login-Screen mit Compose und ViewModel vor. Die Stilfrage lautet nicht nur: „Kompiliert das?“ Die bessere Frage ist: „Kann ein anderer Android-Entwickler schnell erkennen, wo UI, Zustand und Aktion liegen?“ Ein sauberer Stil macht diese Rollen sichtbar.

data class LoginUiState(
    val email: String = "",
    val password: String = "",
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

class LoginViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(LoginUiState())
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()

    fun onEmailChanged(email: String) {
        _uiState.update { currentState ->
            currentState.copy(email = email, errorMessage = null)
        }
    }

    fun onPasswordChanged(password: String) {
        _uiState.update { currentState ->
            currentState.copy(password = password, errorMessage = null)
        }
    }

    fun submitLogin() {
        val state = _uiState.value

        if (state.email.isBlank() || state.password.isBlank()) {
            _uiState.update {
                it.copy(errorMessage = "E-Mail und Passwort dürfen nicht leer sein.")
            }
            return
        }

        _uiState.update { it.copy(isLoading = true, errorMessage = null) }
    }
}

@Composable
fun LoginScreen(
    viewModel: LoginViewModel,
    onLoginSuccess: () -> Unit
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    LoginContent(
        uiState = uiState,
        onEmailChanged = viewModel::onEmailChanged,
        onPasswordChanged = viewModel::onPasswordChanged,
        onSubmit = viewModel::submitLogin
    )
}

@Composable
private fun LoginContent(
    uiState: LoginUiState,
    onEmailChanged: (String) -> Unit,
    onPasswordChanged: (String) -> Unit,
    onSubmit: () -> Unit
) {
    Column {
        TextField(
            value = uiState.email,
            onValueChange = onEmailChanged,
            label = { Text("E-Mail") }
        )

        TextField(
            value = uiState.password,
            onValueChange = onPasswordChanged,
            label = { Text("Passwort") }
        )

        Button(
            onClick = onSubmit,
            enabled = !uiState.isLoading
        ) {
            Text("Anmelden")
        }

        uiState.errorMessage?.let { message ->
            Text(text = message)
        }
    }
}

An diesem Beispiel siehst du mehrere Stilregeln im Alltag. Der UI-Zustand ist ein eigener Typ. Das ViewModel veröffentlicht keine mutable Struktur. Die Event-Funktionen sind nach Benutzeraktionen benannt. LoginScreen bindet das ViewModel an Compose, während LoginContent leichter testbar und wiederverwendbar bleibt. Du kannst in einem Preview oder UI-Test direkt einen LoginUiState übergeben, ohne ein echtes ViewModel zu benötigen.

Eine konkrete Entscheidungsregel: Wenn ein Composable sowohl UI zeichnet als auch fachliche Entscheidungen trifft, prüfe, ob du Zustand und Aktionen auslagern solltest. Nicht jede kleine Bedingung ist ein Problem. Aber sobald Netzwerkzugriff, Validierungslogik, Navigation, Fehlerbehandlung und Layout in derselben Funktion landen, verliert der Code seinen Stil. Er wird schwer lesbar, obwohl er vielleicht noch funktioniert.

Eine typische Stolperfalle ist inkonsistentes Benennen von Events. In einer Datei heißt es onClickLogin, in der nächsten loginClicked, dann performLogin, dann submit. Das klingt harmlos, aber es erhöht die gedankliche Last. Wähle ein Muster und bleibe dabei. Für UI-Callbacks ist onSubmit, onEmailChanged oder onRetry gut lesbar. Für ViewModel-Funktionen passt oft ein aktiver Name wie submitLogin() oder loadProfile().

Eine zweite Stolperfalle ist übertriebene Kürze. Kotlin erlaubt knappe Syntax, aber nicht jede knappe Form ist gut für Lernende oder Teams. Eine lange Chain aus map, filter, also, let und run kann elegant wirken, aber schwer zu debuggen sein. Wenn du beim Setzen eines Breakpoints kaum erkennst, welcher Zwischenschritt falsch ist, ist der Ausdruck zu dicht. Schreibe dann lieber zwei oder drei klare Zwischenschritte mit guten Namen.

Du kannst deinen Stil aktiv prüfen. Lies deinen Code nach dem Schreiben laut in Rollen: Was ist Zustand? Was ist UI? Was ist Event? Was ist Nebenwirkung? Wenn diese Antworten nicht schnell sichtbar sind, braucht der Code bessere Namen oder klarere Grenzen. Im Code-Review solltest du nicht nur fragen, ob der Code korrekt ist, sondern auch, ob er zum restlichen Projekt passt. Tests helfen ebenfalls: Wenn eine Funktion nur schwer isoliert testbar ist, zeigt das oft einen Stil- oder Strukturfehler. In der CI kannst du Formatierung, Lint und Tests regelmäßig laufen lassen, damit Abweichungen früh auffallen.

Fazit

Android-Kotlin-Style ist kein dekorativer Zusatz, sondern ein Arbeitswerkzeug für verlässliche Android-Entwicklung. Du schreibst Kotlin so, dass andere Menschen den Code schnell verstehen, Android-Werkzeuge ihn gut prüfen können und Änderungen nicht unnötig riskant werden. Nimm dir eine vorhandene Datei aus deinem Projekt, prüfe Namen, Zustandsfluss, Sichtbarkeit und Testbarkeit, und verbessere eine Sache bewusst. Danach lässt du Tests, Lint oder ein Review darüber laufen und prüfst, ob dein Code nicht nur läuft, sondern klarer geworden ist.