JSON Naming Convention [chiuso]

Esiste uno standard per la denominazione JSON? Vedo la maggior parte degli esempi usando tutti i caratteri minuscoli separati da trattino basso (minuscolo). Ma puoi usare PascalCase o CamelCase?

Non esiste uno standard SINGOLO, ma ho visto 3 stili che menzioni ("Pascal / Microsoft", "Java" ( camelCase) e "C" (caratteri di sottolineatura, snake_case)) - oltre ad almeno un altro, kebab-casecome longer-name).

Sembra principalmente dipendere da ciò che avevano gli sviluppatori in background del servizio in questione; quelli con background c / c ++ (o lingue che adottano nomi simili, che includono molti linguaggi di scripting, ruby ​​ecc.) spesso scelgono la variante di sottolineatura; e riposare allo stesso modo (Java vs .NET). La libreria Jackson menzionata, ad esempio, assume la convenzione di denominazione dei bean Java ( camelCase)

AGGIORNAMENTO: la mia definizione di "standard" è una convenzione SINGOLA. Quindi, mentre si potrebbe affermare "sì, ci sono molti standard", per me ce ne sono molti Naming Conventions, nessuno dei quali è "lo" standard in generale. Uno di questi potrebbe essere considerato lo standard per una piattaforma specifica, ma dato che JSON viene utilizzato per l'interoperabilità tra piattaforme che possono o non hanno molto senso.

In questo documento Google JSON Style Guide (consigli per la creazione di API JSON su Google),

Si raccomanda che:

1. I nomi delle proprietà devono essere camelCased , stringhe ASCII.

2. Il primo carattere deve essere una lettera, un carattere di sottolineatura (_) o un segno di dollaro ($).

Esempio:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

La mia squadra segue questa convenzione.

Premessa

Non esiste un nome standard per le chiavi in ​​JSON . Secondo la sezione Oggetti delle specifiche:

La sintassi JSON non impone alcuna restrizione alle stringhe utilizzate come nomi, ...

Il che significa che camelCase o snake_case dovrebbero funzionare bene.

Fattori guida

L'imposizione di una convenzione di denominazione JSON è molto confusa. Tuttavia, questo può essere facilmente capito se lo si scompone in componenti.

1. Linguaggio di programmazione per la generazione di JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

2. JSON stesso non ha un nome standard di chiavi

3. Linguaggio di programmazione per l'analisi di JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

Abbina i componenti

1. Python »JSON» Python - snake_case - unanime
2. Python »JSON» PHP - snake_case - unanime
3. Python »JSON» Java - snake_case - vedi sotto il problema Java
4. Python »JSON» JavaScript - snake_case avrà senso; avvitare comunque il front-end
5. Python »JSON» non lo sai - snake_case avrà senso; avvitare comunque il parser
6. PHP »JSON» Python - snake_case - unanime
7. PHP »JSON» PHP - snake_case - unanime
8. PHP »JSON» Java - snake_case - vedi sotto il problema Java
9. PHP »JSON» JavaScript - snake_case avrà senso; avvitare comunque il front-end
10. PHP »JSON» non lo sai - snake_case avrà senso; avvitare comunque il parser
11. Java »JSON» Python - snake_case - vedi sotto il problema Java
12. Java »JSON» PHP - snake_case - vedi sotto il problema Java
13. Java »JSON» Java - camelCase - unanime
14. Java »JSON» JavaScript - camelCase - unanime
15. Java »JSON» non lo sai - camelCase avrà un senso; avvitare comunque il parser
16. JavaScript »JSON» Python - snake_case avrà senso; avvitare comunque il front-end
17. JavaScript »JSON» PHP - snake_case avrà senso; avvitare comunque il front-end
18. JavaScript »JSON» Java - camelCase - unanime
19. JavaScript »JSON» JavaScript - camelCase - Originale

Problema Java

snake_case avrà ancora senso per quelli con voci Java perché le librerie JSON esistenti per Java stanno usando solo metodi per accedere alle chiavi invece di usare il dot.syntax standard . Ciò significa che Java non farebbe molto male l'accesso alle chiavi snake_cased rispetto all'altro linguaggio di programmazione che può eseguire dot.syntax .

Esempio per il pacchetto Javaorg.json

JsonObject.getString("snake_cased_key")

Esempio per il pacchetto Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Alcune implementazioni effettive

• API JavaScript di Google Maps - camelCased
• API JavaScript di Facebook - snake_cased
• Amazon Web Services - snake_cased & camelCased
• API di Twitter - snake_cased
• JSON-LD - camelCased & ProperCamelCased

conclusioni

La scelta della giusta convenzione di denominazione JSON per l'implementazione JSON dipende dallo stack tecnologico. Ci sono casi in cui è possibile usare snake_case , camelCase o qualsiasi altra convenzione di denominazione.

Un'altra cosa da considerare è il peso da mettere sul generatore JSON rispetto al parser JSON e / o al JavaScript front-end. In generale, si dovrebbe mettere più peso sul lato del generatore JSON piuttosto che sul lato del parser JSON. Questo perché la logica aziendale di solito risiede sul lato del generatore JSON.

Inoltre, se il lato JSON-parser è sconosciuto, puoi dichiarare ciò che mai può funzionare per te.

In particolare per me su NodeJS, se sto lavorando con database e i miei nomi dei campi sono separati da sottolineatura, li uso anche nelle chiavi struct.

Questo perché i campi db hanno molti acronimi / abbreviazioni, quindi qualcosa come appSNSInterfaceRRTest sembra un po 'disordinato ma app_sns_interface_rr_test è più bello.

In Javascript le variabili sono tutte camelCase e i nomi delle classi (costruttori) sono ProperCase, quindi vedresti qualcosa di simile

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

o

generalLedgerTask = new GeneralLedgerTask( devTask );

E ovviamente nelle chiavi / stringhe JSON sono racchiuse tra virgolette doppie, ma poi basta usare JSON.stringify e passare oggetti JS, quindi non devi preoccuparti di questo.

Ho lottato un po 'con questo fino a quando ho trovato questo mezzo felice tra le convenzioni di denominazione JSON e JS.

Sembra che ci sia abbastanza variazione che le persone fanno di tutto per consentire la conversione da tutte le convenzioni ad altre: http://www.cowtowncoder.com/blog/archives/cat_json.html

In particolare, preferisce il menzionato parser Jackson JSON bean_naming.

Penso che non ci sia una convenzione ufficiale di denominazione per JSON, ma puoi seguire alcuni leader del settore per vedere come funziona.

Google, che è una delle più grandi società IT del mondo, ha una guida di stile JSON: https://google.github.io/styleguide/jsoncstyleguide.xml

Approfittando, puoi trovare una guida agli altri stili, definita da Google, qui: https://github.com/google/styleguide

Come altri hanno affermato, non esiste uno standard, quindi dovresti sceglierne uno tu stesso. Ecco un paio di cose da considerare quando lo fai:

1. Se si utilizza JavaScript per utilizzare JSON, l'utilizzo della stessa convenzione di denominazione per le proprietà in entrambi fornirà coerenza visiva e, eventualmente, alcune opportunità per un riutilizzo del codice più pulito.

2. Un piccolo motivo per evitare il caso di kebab è che i trattini possono scontrarsi visivamente con -caratteri che compaiono in valori.

   {
     "bank-balance": -10
   }