Datenübertragung, -speicherung und Konfiguration. Das sind die häufigsten Einsatzzwecke von JSON und YAML. Ja, es gibt gute Gründe, warum beide Sprachen derart weitverbreitet sind. Vor allem JSON ist nicht nur sehr flexibel und vielseitig einsetzbar, sondern wird von den meisten Programmiersprachen und Tools teilweise sogar nativ unterstützt. Auch kommen viele Entwickler bereits sehr früh mit JSON in Kontakt und wissen dann bereits, wie damit umzugehen ist. Dennoch sollte JSON hauptsächlich zur Datenübertragung verwendet werden. Doch auch YAML ist nicht die beste Alternative wenn es um Konfigurationssprachen geht.

JSON wurde hauptsächlich für die Datenübertragung entwickelt. Das Format ist für die Maschine leicht zu interpretieren und auch der Mensch kann die Datei gut lesen. Als Konfigurationssprache fällt JSON jedoch für viele Projekte aus mehreren Gründen durch. Für diesen Einsatzzweck wurde das Format auch nicht geschaffen. Dennoch kommt es dafür immer häufiger zum Einsatz. Die Gründe dafür stehen im ersten Absatz: Die native Unterstützung bei vielen Programmiersprachen und die weite Verbreitung von JSON sorgen für eine schnelle und einfache Implementierung. Das sind durchaus berechtigte Argumente und deswegen macht JSON als Konfigurationssprache für einige Entwickler und Projekte Sinn.

Jedoch gibt es auch Gründe, warum JSON als Konfigurationssprache weniger gut geeignet ist und das sollte Entwicklern bewusst sein, wenn sie sich für JSON entscheiden. Eins der größeren Probleme bei JSON ist eine fehlende Kommentar-Funktion. Bei Konfigurationssprachen sind Kommentare ein wichtiger Bestandteil, um gewisse Teile der Konfiguration näher zu erläutern oder eine gewählte Einstellung zu begründen. Es gibt zwar durchaus einige Workarounds oder Libraries für Kommentare, jedoch existiert keine native Lösung, weswegen derartige Alternativen schnell an anderer Stelle Probleme auslösen könnten.

Weitere Gründe gegen JSON stecken im Detail. Ja, JSON ist zwar relativ gut lesbar, aber auch nicht so gut, dass man das Format für Konfigurationszwecke nutzen sollte. So müssen Schlüssel immer in Anführungszeichen gesetzt werden. Außerdem helfen die geschweiften Klammern, die das gesamte Dokument einschließen, JavaScript die Datei einzulesen. Das sorgt jedoch für ein Klammer-Wirrwarr und ist für den Entwickler eher nervig. Ähnlich bei den durch Kommata abgetrennten Schlüssel-Wert-Paaren. Dort wäre ein einfacher Zeilenumbruch ausreichend. Eine JSON-Datei in einer Zeile zu lesen oder gar zu konfigurieren, ist sowieso alles andere als eine gute Idee. Apropos eine Zeile: Mit langen Strings hat JSON ebenfalls so seine Probleme. Wollt ihr in einem langen Text Zeilenumbrüche einbauen, muss explizit „n“ eingesetzt werden.

Einige Entwickler setzen stattdessen auf YAML als Konfigurationssprache. Die Sprache merzt einige der JSON-Probleme aus. So unterstützt das Format nicht nur komplett leere und mehrzeilige Strings, sondern auch Kommentare sowie weitere Variablentypen. Auch kann auf vorherige Werte in der YAML-Datei verwiesen werden. Klingt alles super, doch ein Aspekt kann schnell zu Problemen führen: Es wird jeweils mit Leerzeichen statt einem Tab eingerückt und die sind an entsprechenden Stellen auch verpflichtend. Passt ihr die Konfigurationsdatei nun per Hand an, kann euch das schnell zur Weißglut bringen. Vor allem bei größeren Konfigurationen, die in viele Ebenen unterteilt sind und mehrere 100 Zeilen lang sind. Denn wenn du ein Leerzeichen vergisst oder zu viel eingebaut hast, macht das die komplette Datei unlesbar. Solche Fehler sind zudem nicht leicht zu finden. Entsprechende Entwicklungsumgebungen können dabei jedoch eine große Hilfe sein, wenn sie bei der Verwendung der Tab-Taste Leerzeichen einfügen.

Außerdem ist die Spezifikation von YAML sehr komplex. Sie umfasst über 80 Seiten. Zum Vergleich: Bei JSON sind es, wenn man leere Seiten außen vor lässt, nicht mehr als zehn Seiten. Für mehr Features wird auch eine längere Spezifikation benötigt. Ist sie jedoch acht Mal so lang, spricht das eher für eine zu hohe Komplexität der Sprache. So gibt es beispielsweise ganze neun verschiedene Möglichkeiten, einen mehrzeiligen String zu verfassen. Und jede der Möglichkeiten hat eine minimal andere Funktion. Wer soll sich das alles vollständig merken können?

Das sind die Probleme mit JSON:

• Zur Datenübertragung ist JSON ein solides Format
• Als Konfigurationssprache ist von JSON in vielen Fällen abzuraten: nicht so gut lesbar, fehlende Features wie mehrzeilige Strings, Anführungszeichen bei Schlüsseln und Kommata nach jedem Schlüssel-Wert-Paar.

YAML kann eine bessere Alternative sein, hat jedoch auch ein paar Tücken:

• Hat viele Features die JSON fehlen: Kommentare, mehrzeilige oder leere Strings, viele Variablentypen.
• Hauptproblem: Einrückung per Leerzeichen statt Tab. Vor allem bei langen Konfigurationen ein Problem.
• Sehr Komplex: Konfiguration umfasst acht Mal mehr Seiten als die von JSON.

HCL scheint eine Mischung aus JSON und YAML zu sein. Die wichtigsten Features sind so verpackt, dass sie für den Menschen weiterhin gut lesbar und verständlich sind. Wohl einer der Gründe, warum auch die neuen GitHub Actions die Sprache zur Konfiguration benutzen. Es werden Kommentare, mehrzeilige Strings und verschiedene Zahlenformate wie Hexadezimal und Oktal unterstützt. Auch verringert HCL durch schlauere Syntax die Tiefe bei verschachtelten Objekten im Vergleich zu JSON.

number = 10
hexa = 0xFF
octal = 0123

// Das ist ein Kommentar
workflow "IDENTIFIER" {
  on = "EVENT"
  resolves = "ACTION2"
}
# Auch das ist ein Kommentar
action "EXAMPLE1" {
  uses = "docker://image1"
}
/*
Ein mehrzeiliger
Kommentar
*/
action "EXAMPLE2" {
  needs = "ACTION1"
  uses = "docker://image2"
}

Passend dazu: So optimiert ihr mit HJSON euren JSON-Syntax

Wer mit der Grundstruktur von JSON zufrieden ist und lediglich mehr Features benötigt, sollte sich HJSON oder auch JSON5 anschauen. So könnt ihr nun Kommentare und mehrzeilige Strings nutzen. Anführungszeichen können bei Schlüsseln und Strings weggelassen werden – genauso wie Kommata zwischen Schlüssel-Wert-Paaren. Außerdem findet ihr im Internet einige Tools, die euch das jeweilige Format wieder zu einer JSON-Datei konvertieren können, falls ihr das benötigt.

Ein Beispiel in HJSON:

{
  // use #, // or /**/ comments,
  // omit quotes for keys
  key: 1
  // omit quotes for strings
  contains: everything on this line
  // omit commas at the end of a line
  cool: {
    foo: 1
    bar: 2
  }
  // allow trailing commas
  list: [
    1,
    2,
  ]
  // and use multiline strings
  realist:
    '''
    My half empty glass,
    I will fill your empty half.
    Now you are half full.
    '''
}

Welche Konfigurationssprache ihr am Ende nutzen solltet, hängt stark von eurer Situation ab. Da es viele weitere Alternativen gibt und hier nicht genug Platz für eine ausführliche Vorstellung ist, findet ihr im Folgenden weitere Beispiele als kurze Liste:

• TOML: Ähnlich zum INI-Format. Hat jedoch auch eine Syntax für verschachtelte Objekte. Habt ihr jedoch eine große Struktur mit vielen Ebenen, ist TOML nicht die beste Wahl.
• HOCON: Verbreitet bei Scala-Projekten. Hat ebenfalls alle wichtigen Features an Bord und ist eine Obermenge von JSON, wodurch JSON-Dateien direkt verwendet werden können.
• Protocol Buffers: Entwickelt von Google und wird mit den Wörtern „XML, aber kleiner, schneller und einfacher“ beschrieben.
• AXON: Kombiniert die Einfachheit von JSON, Erweiterbarkeit von XML und Lesbarkeit von YAML.

Und noch viele viele weitere. Nutzt du eine ganz andere Konfigurationssprache? Dann schreib sie in die Kommentare und erkläre, warum du dich für sie entschieden hast.

Wer Programmieren lernen will, muss Informatik studieren. Ein Irrglaube, der immer noch weit verbreitet ist. Warum das eben genau nicht der Fall. Lies dazu: Warum ihr zum Programmieren lernen nicht studieren müsst.