Ratgeber

Warum JSON und YAML keine guten Konfigurationssprachen sind

Seite 2 / 2

Das sind JSON- und YAML-Alternativen

HCL – Hashicorp Configuration Language

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"
}

HJSON und JSON5 – wie JSON, aber mit mehr Features

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.
    '''
}

Weitere Alternativen zusammengefasst

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.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

7 Kommentare
M.S.
M.S.

Die Überschrift „Warum JSON und YAML keine guten Konfigurationssprachen sind“ alleine beinhaltet schon ein Wertung und stellt JSON, YAML grundsätzlich als schlechte Wahl dar. Der Artikel ist entsprechend weiter so formuliert.

Wenn jemand JSON oder YAML für sich als Konfigurationsformat gefunden hat ist dieses in meinen Augen nicht grundsätzlich schlecht. Zudem ist der auch benannte Vorteil – Unterstützung in diversen Sprachen – nicht zu unterschätzen.

Der Aufbau von JSON kann auch verständlich lesbar erfolgen, hierzu müssen z.B. die Keys sprechend formuliert werden.

Am Ende muss jeder für sich entscheiden welches Konfigurationsformat für Ihn in Frage kommt.

Ich hatte mir von dem Artikel mehr Sachlichkeit und eine bessere Gegenüberstellung der Alternativen erhofft. So aber bleibt bei mir der Eindruck das dieser Artikel nur einer Meinungäußerung dient.

Antworten
Jarek Sarbiewski
Jarek Sarbiewski

Den Eindruck hatte ich auch.

Ich persoenlich nutze XML fuer eigene Datenformate und als Konfigurationssprache. Falls es auf die Datenmenge ankommt, nutze ich stattdessen JSON. Mit beiden hatte ich nie Probleme. Naturlich benoetigt man evtl. die anderen Features falls die Konfigurationsdaten sehr gross werden um den Ueberblick nicht zu verlieren. Trotzdem wurden in diesem Artikel JSON und YAML als Konfigurationssprache pauschal fuer ungeeignet deklariert.

Antworten
Andreas Domin

Hallo M.S.,

die Überschrift für sich stellt noch keine Wertung dar. Die Gründe dafür stehen im Artikel. Jedoch muss ich dir in den weiteren Punkten recht geben, weswegen die Argumentation im Artikel durchaus fehlende sachliche Aspekte hatte. Ich habe mir den Artikel noch einmal genauer vorgenommen und entsprechend überarbeitet.

Viele Grüße aus Hannover
Andreas

Antworten
Robert W.
Robert W.

und wo sind jetzt die Argumente gegen JSON und YML?

so im Produktiveinsatz hab ich die genannten Probleme nicht gehabt. Eine Konfiguration mit mehrzeiligen Strings ist schlecht aufgebaut bzw. der Autor sollte überlegen, ob es Sinn macht Zeilenumbrüche in eine Konfiguration zu schreiben.

Kommentare können btw. auch der Ausdruck von schlecht verständlichem Code sein.

Schlussendlich ist es wie mit aller Technologie: es gibt kein richtig oder falsch, denn „it (always) depends“

Antworten
Andreas Domin

Hallo Robert,

ich habe mir den Artikel noch einmal genauer vorgenommen und überarbeitet. Die Argumente gegen JSON und YAML stehen im Text.

Kommentare sind aber meiner Meinung nach auf keinen Fall ein Ausdruck von schlecht verständlichem Code. Im Gegenteil. Fehlende Kommentare sind ein Ausdruck davon. Warum hat beispielsweise ein Entwickler-Kollege in einer Konfiguration eine gewisse Einstellung getroffen? Solche Dinge können Monate oder gar Jahre nach der Bearbeitung nicht immer nachvollzogen werden. Kommentare sind ein extrem wichtiger Bestandteil eines guten Codes – auch bei den allermeisten Konfigurationen.

Deinem letzten Satz muss ich jedoch zustimmen. Ich habe den Artikel dahingehend auch angepasst.

Viele Grüße
Andreas

Antworten
Dominic Karasch
Dominic Karasch

Ich sehe das recht ähnlich – jeder muss das richtige Format für sich selbst finden. Ich persönlich arbeite seit knapp über 4 Jahren mit YAML als Konfigurationssprache und bin durchaus zufrieden.

Für mich liest sich der Part über YAML so, als wenn der Autor die Sprache nicht selbst probiert hat und die Dokumentation dazu auch nicht genau gelesen hat. Tabs können bei YAML genau so wie Spaces genutzt werden. Ich selbst nutze sogar 4 Spaces anstatt von 2. Als Entwickler hat man ja in der Regel auch eine IDE im Einsatz, bei der man z.B. die Nutzung der Tabs speziell für YAML auch einstellen kann und diese zu Spaces gewandelt werden.

Es fehlen hier auch einfach wichtige Punkte die für YAML widerrum sprechen würden, wie zum Beispiel die Möglichkeit der Importierung in eine andere Datei oder das überschreiben von Werten, die Nutzung einer verschlüsselten Form (eYAML), und vieles mehr.

Die Objektivität in diesem Artikel ist komplett untergegangen und wirkt eher wie ein eingesendeter Brief, einer Person die YAML und JSON einfach nicht mag bzw. bevorzugt. Ich hätte mir deutlich mehr erhofft!

Antworten
Andreas Domin

Hallo Dominic,

ich muss dir in einigen Aspekten zustimmen und ich habe den Artikel entsprechend ein wenig überarbeitet.

Und ich habe bereits längere Zeit mit YAML gearbeitet und habe leider schlechte Erfahrung für diesen Einsatzzweck gemacht. Aber wie in anderen Kommentaren bereits stand: Es kommt auf den Einsatz und den Entwickler an. Von daher habe ich mehr Objektivität eingebracht.

Viele Grüße aus Hannover
Andreas

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung