JSON-Namenskonvention (snake_case, camelCase oder PascalCase)

Question

Gibt es einen Standard für die Benennung von JSON?
In den meisten Beispielen werden alle Kleinbuchstaben durch einen Unterstrich getrennt, auch bekannt als snake_case aber kann es verwendet werden PascalCase ou camelCase auch?

Answer 1

In diesem Dokument Google JSON Style Guide (Empfehlungen für die Erstellung von JSON-APIs bei Google),

Sie empfiehlt dies:

1. Eigenschaftsnamen müssen sein camelCased ASCII-Zeichenfolgen.

2. Das erste Zeichen muss ein Buchstabe, ein Unterstrich (_) oder ein Dollarzeichen ($) sein.

Beispiel:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Mein Team folgt bei der Erstellung von REST-APIs konsequent dieser Konvention. Dafür gibt es einige Gründe:

• Erstens sollte die JSON-Konvention unabhängig von den Programmiersprachen sein, denn wir wollen, dass unsere APIs konsistent sind, unabhängig davon, ob es APIs gibt, die mit einer camelCase Sprache (z. B. Java), einige andere mit snake_case Sprache (z.B. Python).
• Außerdem sind die meisten unserer Kunden Webanwendungen, so dass camelCase wird bevorzugt
• Wenn der Kunde es vorzieht snake_case kann es dennoch problemlos Daten konvertieren zwischen snake_case y camelCase (mit Hilfe von Bibliotheken)

Ich stimme jedoch zu, dass, wenn alle Anwendungen die gleiche Art von Sprache verwenden (z. B. snake_case ), sollte auch die JSON-Konvention eingehalten werden.

Answer 2

ECMA-404

Die JSON-Syntax enthält keine Einschränkungen für die als Namen verwendeten Zeichenfolgen,...

Es gibt keine Norm Benennung von Schlüsseln in JSON und dass camelCase o schlangen_koffer sollte gut funktionieren.

TL;DR

Hier ist ein Faustformel die wohl von den meisten Entwicklern verwendet wird.

Technologie-Stapel

Konvention zur Namensgebung

Grund/ Leitfaden

Python  " JSON "  Python

schlangen_koffer

Einstimmig

Python  " JSON "  PHP

schlangen_koffer

Einstimmig

Python  " JSON "  Java

snake_case oder camelCase

Legen Sie fest, wo sich die Geschäftslogik befindet. Nutzen Sie die Vorteile des extrinsischen Stils von Java.

Python  "JSON " Backend  JavaScript

snake_case oder camelCase

Legen Sie fest, wo sich die Geschäftslogik befindet.

Python  "JSON " Frontend  JavaScript

schlangen_koffer

Scheiß auf das Front-End

Python  " JSON "  Sie wissen nicht

schlangen_koffer

Scheiß auf den Parser

PHP  " JSON "  Python

schlangen_koffer

Einstimmig

PHP  " JSON "  PHP

schlangen_koffer

Einstimmig

PHP  " JSON "  Java

snake_case oder camelCase

Legen Sie fest, wo sich die Geschäftslogik befindet. Nutzen Sie die Vorteile des extrinsischen Stils von Java.

PHP  "JSON " Backend  JavaScript

snake_case oder camelCase

Legen Sie fest, wo sich die Geschäftslogik befindet.

PHP  "JSON " Frontend  JavaScript

schlangen_koffer

Scheiß auf das Front-End

PHP  " JSON "  Sie wissen nicht

schlangen_koffer

Scheiß auf den Parser

Java  " JSON "  Python

camelCase oder snake_case

Legen Sie fest, wo sich die Geschäftslogik befindet. Nutzen Sie die Vorteile des extrinsischen Stils von Java.

Java  " JSON "  PHP

camelCase oder snake_case

Legen Sie die Geschäftslogik dort ab, wo sie sich befindet. Nutzen Sie die Vorteile des extrinsischen Stils von Java.

Java  " JSON "  Java

camelCase

Einstimmig

Java  " JSON "  JavaScript

camelCase

Einstimmig

Java  " JSON "  Sie wissen nicht

camelCase

Scheiß auf den Parser

Backend  JavaScript  " JSON "  Python

camelCase oder snake_case

Legen Sie fest, wo sich die Geschäftslogik befindet.

Vorderseite  JavaScript  " JSON "  Python

schlangen_koffer

Scheiß auf das Front-End

Backend  JavaScript  " JSON "  PHP

camelCase oder snake_case

Legen Sie fest, wo sich die Geschäftslogik befindet.

Vorderseite  JavaScript  " JSON "  PHP

schlangen_koffer

Scheiß auf das Front-End

JavaScript  " JSON "  Java

camelCase

Einstimmig

JavaScript  " JSON "  JavaScript

camelCase

Original

JavaScript  " JSON "  Sie wissen nicht

camelCase

Scheiß auf den Parser

Treibende Faktoren

Die Festlegung einer Namenskonvention ist sehr verwirrend, da JSON allein keinen Standard vorschreibt. Dies kann jedoch leicht herausgefunden werden, wenn man es in Komponenten aufteilt.

JSON-Generator

Programmiersprache

Konvention zur Namensgebung

Python

schlangen_koffer

PHP

schlangen_koffer

Java

camelCase

JavaScript

camelCase

JSON-Parser

Programmiersprache

Konvention zur Namensgebung

Python

schlangen_koffer

PHP

schlangen_koffer

Java

camelCase

JavaScript

camelCase

Großteil der Geschäftslogik

Sie müssen entscheiden, welche Seite die schwerwiegendere Geschäftslogik hat, ist es die JSON-Generator Seite oder die JSON-Parser Seite?

Natürliche Zugehörigkeit

Programmiersprache

Natürliche Zugehörigkeit

Python

immanent

PHP

immanent

Java

Extrinsisch

JavaScript

immanent

Intrinsisch - Programmiersprache, in der auf JSON zugegriffen wird natürlich ähnlich zum Zugriff auf native Objekte und Arrays.

Extrinsisch - Programmiersprache, in der auf JSON zugegriffen wird anders als der Zugriff auf native Objekte und Arrays. Nachstehend ein Beispiel für Java 's com.google.gson Paket:

/**
 * Using a method to access a property instead of using the standard 'dot.syntax'
 */
JsonElement.getAsString("snake_cased_key");

Einige konkrete Umsetzungen

• Google Maps JavaScript-API - camelCased
• Facebook JavaScript-API - Schlange_verkleidet
• Amazon Webdienste - Schlange_verkleidet & camelCased
• Twitter-API - Schlange_verkleidet
• JSON-LD - camelCased

Schlussfolgerungen

Die Wahl der richtigen JSON-Benennungskonvention für Ihre JSON-Implementierung hängt von Ihrem Technologie-Stack ab. Es gibt Fälle, in denen Sie Folgendes verwenden können schlangen_koffer , camelCase oder eine andere Namenskonvention.

Eine weitere Überlegung ist die Gewichtung des JSON-Generators gegenüber dem JSON-Parser und/oder dem Front-End-JavaScript. Im Allgemeinen sollte der Geschäftslogik mehr Gewicht beigemessen werden.

Auch, wenn die JSON-Parser Seite unbekannt ist, dann können Sie deklarieren, was immer für Sie arbeiten kann.

Answer 3

Es gibt keinen EINZIGEN Standard, aber ich habe die 3 von Ihnen genannten Stile gesehen ("Pascal/Microsoft", "Java" ( camelCase ) und "C" (Unterstriche, snake_case )) - sowie mindestens eine weitere, kebab-case wie longer-name ).

Es scheint vor allem davon abzuhängen, welchen Hintergrund die Entwickler des betreffenden Dienstes hatten; diejenigen mit C/C++-Hintergrund (oder Sprachen, die eine ähnliche Namensgebung verwenden, wozu viele Skriptsprachen, Ruby usw. gehören) wählen oft die Unterstrich-Variante; und der Rest ist ähnlich (Java vs. .NET). Die erwähnte Jackson-Bibliothek zum Beispiel übernimmt die Java-Bean-Namenskonvention ( camelCase )

UPDATE: Meine Definition von "Standard" ist eine EINZIGE Konvention. Während man also behaupten könnte "ja, es gibt viele Standards", gibt es für mich mehrere Naming Conventions , die allesamt nicht "der" Standard sind. Einer von ihnen könnte als der Standard für eine bestimmte Plattform angesehen werden, aber da JSON für die Interoperabilität zwischen Plattformen verwendet wird, kann das viel Sinn machen oder auch nicht.

Answer 4

Vor allem für mich auf NodeJS, wenn ich mit Datenbanken arbeiten und meine Feldnamen sind Unterstrich getrennt, ich verwende sie auch in der Struktur Schlüssel.

Der Grund dafür ist, dass Datenbankfelder viele Akronyme/Abkürzungen haben, so dass etwas wie appSNSInterfaceRRTest sieht ein bisschen unordentlich aus, aber app_sns_schnittstelle_rr_test ist schöner.

In Javascript sind Variablen alle camelCase und Klassennamen (Konstruktoren) sind ProperCase, so dass Sie etwas wie sehen würde

var devTask = {
        task_id: 120,
        store_id: 2118,
        task_name: 'generalLedger'
    };

または

generalLedgerTask = new GeneralLedgerTask( devTask );

Und natürlich in JSON Schlüssel/Zeichenfolgen sind in Anführungszeichen eingewickelt, aber dann verwenden Sie einfach die JSON.stringify und übergeben in JS-Objekte, so brauchen nicht zu kümmern.

Ich kämpfte ein wenig damit, bis ich den goldenen Mittelweg zwischen JSON- und JS-Benennungskonventionen fand.

Answer 5

Anscheinend gibt es so viele verschiedene Konventionen, dass die Leute sich Mühe geben, die Umstellung von allen Konventionen auf andere zu ermöglichen: http://www.cowtowncoder.com/blog/archives/cat_json.html

Insbesondere der erwähnte Jackson JSON-Parser bevorzugt bean_naming .