Die Kotlin-Dokumentation verbindet Lernen, Sprachreferenz, Plattformen, API-Referenz und Migrationen.
Für den strukturellen Teil wurden DocLint-Regeln verwendet, die redaktionelle Bewertung erfolgte manuell anhand offizieller Quellen.
Untersuchungsumfang
Öffentlicher Stand vom 15. August 2026.
Markdown-Themen
.topic-Dateien
Tour-Lektionen
stabile Version
Kriterien
Kein einziges großes Handbuch
Lernen, Aufgaben, Konzepte, Referenz und Release-Inhalte sind getrennt.
| Nutzerziel | Ziel | Ergebnis |
|---|---|---|
| Ausprobieren | Tour und Playground | Ohne IDE starten. |
| Projekt starten | Get started | Nach Plattform und Ziel. |
| Sprache verstehen | Language guide | Konzepte und Syntax. |
| API nachschlagen | Dokka | Separate Referenz. |
| Aktualisieren | What’s new und Migration | Versionsbezogene Inhalte. |
| Bibliothek bauen | KDoc und Author Guidelines | Qualität öffentlicher APIs. |
Technische Umsetzung
Reife Docs-as-Code-Architektur.
Markdown + Writerside
Inhalte und Navigation.
Mehrere Repositories
Externe Docs werden eingebunden.
CI
Ausführbare Beispiele werden geprüft.
Publikation
TeamCity baut und verarbeitet nach.
Redaktionelle Bewertung: 82/100
Sehr stark bei Einstieg, Beispielen und Engineering. Schwächer bei Lokalisierung und Troubleshooting.
82/100
Besonders stark
Tour ohne Installation
[K3]16 Browser-Lektionen.
Geprüfte Beispiele
[G4]Runnable snippets werden in CI geprüft.
Navigation als Code
[G3]kr.tree versioniert die Struktur.
Release-Dokumentation
[K10]Dokumentationsänderungen werden mit Releases gepflegt.
Author Guidelines
[K7]Personas, Fehlerfälle und API-Design.
AI-gestützte Wartung
[G7]Das Repository enthält reproduzierbare Skills.
Starke und schwache Formulierungen
Gutes Engineering ersetzt kein Editing.
| Kriterium | Formulierung | Analyse |
|---|---|---|
| Gut | “New to Kotlin? Take our tour…” [K2] | Direkt und handlungsorientiert. |
| Gut | “Begin the description of entry points…” [K7] | Prüfbare Regel. |
| Überarbeiten | “The Kotlin Standard Library provides…” [K5] | Zu abstrakter Einstieg. |
| Korrigieren | “Attempting to access properties…” [K4] | Das folgende Beispiel zeigt einen Compile-Fehler. |
Was fehlt
Entwicklung
Was man übernehmen sollte
| Praxis | Übernehmen |
|---|---|
| Navigation als Code | Informationsarchitektur versionieren. |
| Geprüfte Beispiele | Codebeispiele in CI testen. |
| Inhaltstypen trennen | Tutorial, Konzept und Referenz nicht vermischen. |
| Release Docs | Migration zusammen mit dem Produkt aktualisieren. |
| Docs als Designtest | Schwieriges Onboarding kann auf schwierige API hinweisen. |
| AI mit Skills | Agenten konkrete, prüfbare Abläufe geben. |
Primärquellen
Fazit
Kotlin ist vor allem als Produktionssystem für Dokumentation stark.
Der Leserweg trennt Lernen, Konzepte, Referenz und Migration sinnvoll.
Die größten Chancen liegen bei Lokalisierung, Troubleshooting und straffer Redaktion.
Kotlin zeigt eine reife Dokumentationsarchitektur mit geprüften Beispielen und automatisierbarer Wartung.
