bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/.github/kotlin-conventions.instructions.md
Jens Reinemann a5f89e6a69 rename: Krisenvorrat -> Bollwerk 
- Package: de.krisenvorrat.* -> de.bollwerk.*
- Klassen: KrisenvorratApp/Database/Theme -> Bollwerk*
- ApplicationId: de.bollwerk.app
- Server: BOLLWERK_* Env-Vars, bollwerk HOCON-Config
- Docker: bollwerk-server/db/backup Container-Namen
- Room DB: bollwerk.db, SharedPrefs: bollwerk_secure_prefs
- Export-Dateien: bollwerk_export/inventar
- UI-Strings, HTML, Admin-UI: alle auf Bollwerk
- Docs, Skills, README angepasst
- Alle Tests gruen, Build erfolgreich
2026-05-17 17:44:02 +02:00

2 KiB
Raw Blame History

applyTo
**/*.kt

Kotlin Coding Conventions – Bollwerk App

Diese Konventionen gelten für alle Kotlin-Dateien im Workspace.

Sprache & Plattform

  • Kotlin (aktuell), Zielplattform Android (aktuelles API-Level)
  • Jetpack Compose für UI
  • Gradle (Kotlin DSL) als Build-System

State Management

  • StateFlow / MutableStateFlow in ViewModels
  • collectAsStateWithLifecycle() in Composables
  • remember / rememberSaveable für UI-lokalen State

Navigation

  • Jetpack Navigation Compose
  • Type-safe Navigation mit @Serializable Routen

Concurrency

  • Kotlin Coroutines (suspend, Flow, StateFlow)
  • viewModelScope für ViewModel-gebundene Coroutines
  • withContext(Dispatchers.IO) für I/O-Operationen
  • Strukturierte Fehlerbehandlung mit try/catch um jeden suspend-Aufruf

Naming

  • Klassen/Interfaces: UpperCamelCase
  • Funktionen/Variablen: lowerCamelCase
  • Konstanten: UPPER_SNAKE_CASE
  • Composable-Funktionen: UpperCamelCase (wie Klassen)
  • Boolean-Eigenschaften: Präfix is, has, can, should

Zugriffsmodifikatoren

  • So restriktiv wie möglich: private > internal > public
  • Kein public ohne klaren Grund (Kotlin-Default ist public)

Verbotene Patterns

  • Keine Force-Casts (as) ohne vorherige Typprüfung – as? bevorzugen
  • Keine println()-Statements – stattdessen Timber oder Projekt-Logger verwenden
  • Keine ungenutzten Imports
  • Keine auskommentierten Code-Blöcke
  • Kein !! (not-null assertion) in Produktionscode

Testing

  • JUnit 5 für Unit Tests
  • Espresso / Compose Testing für UI Tests
  • Testmethoden: test_<Was>_<Vorbedingung>_<Ergebnis>()
  • Gliederung: // Given, // When, // Then
  • MockK für Mocking

Persistenz

  • Room (SQLite) für lokale Daten
  • kotlinx.serialization für JSON Import/Export
  • DataStore für Einstellungen/Konfigurationen
  • Keychain für Session-Tokens

Dokumentation

  • Alle öffentlichen/internen Typen und Methoden mit /// dokumentieren
  • Kommentare beschreiben „was" und „warum", nicht „wie"