Konwencja nazewnictwa JSON [zamknięta]

Czy istnieje standard nazewnictwa JSON? Widzę większość przykładów, w których wszystkie małe litery są oddzielone podkreśleniem (small_case). Ale czy możesz użyć PascalCase lub camelCase?

Nie ma POJEDYNCZEGO standardu, ale widziałem 3 style, o których wspominasz („Pascal / Microsoft”, „Java” ( camelCase) i „C” (podkreślenia, snake_case)) - a także co najmniej jeden kebab-casepodobny longer-name.

Wydaje się, że zależy to głównie od tego, jakie były tła twórców omawianej usługi; osoby z tłem c / c ++ (lub języki, które przyjmują podobne nazewnictwo, w tym wiele języków skryptowych, ruby ​​itp.) często wybierają wariant podkreślenia; i odpoczywać podobnie (Java vs .NET). Wspomniana biblioteka Jackson, na przykład, przyjmuje konwencję nazewnictwa komponentów Java Bean (camelCase )

AKTUALIZACJA: moja definicja „standardu” to JEDNA konwencja. Tak więc, chociaż można powiedzieć „tak, istnieje wiele standardów”, dla mnie istnieje wiele Naming Conventions, z których żaden nie jest ogólnie „standardem”. Jeden z nich można uznać za standard dla konkretnej platformy, ale biorąc pod uwagę, że JSON jest używany do współdziałania między platformami, które mogą, ale nie muszą mieć większego sensu.

W tym dokumencie Przewodnik po stylu Google JSON (zalecenia dotyczące tworzenia interfejsów API JSON w Google),

Zaleca:

1. Nazwy właściwości muszą być wielbłądami , ciągami ASCII.

2. Pierwszym znakiem musi być litera, znak podkreślenia (_) lub znak dolara ($).

Przykład:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Mój zespół przestrzega tej konwencji.

Przesłanka

W JSON nie ma standardowego nazewnictwa kluczy . Zgodnie z sekcją Obiekty specyfikacji:

Składnia JSON nie nakłada żadnych ograniczeń na ciągi używane jako nazwy ...

Co oznacza, że camelCase lub snake_case powinny działać poprawnie.

Czynniki napędzające

Nałożenie konwencji nazewnictwa JSON jest bardzo mylące. Można to jednak łatwo zrozumieć, jeśli podzielisz go na części.

1. Język programowania do generowania JSON

   • Python - snake_case
   • PHP - skrzynka węża
   • Java - camelCase
   • JavaScript - camelCase

2. Sam JSON nie ma standardowej nazwy kluczy

3. Język programowania do analizy JSON

   • Python - snake_case
   • PHP - skrzynka węża
   • Java - camelCase
   • JavaScript - camelCase

Dopasuj składniki

1. Python »JSON» Python - snake_case - jednogłośnie
2. Python »JSON» PHP - skrzynka węża - jednogłośnie
3. Python »JSON» Java - snake_case - zobacz problem Java poniżej
4. Python »JSON» JavaScript - obudowa węża będzie miało sens; i tak przykręć front
5. Python »JSON» nie wiesz - snake_case będzie miało sens; i tak przekręć parser
6. PHP »JSON» Python - skrzynka węża - jednogłośnie
7. PHP »JSON» PHP - skrzynka węża - jednogłośnie
8. PHP »JSON» Java - skrzynka węża - zobacz problem z Javą poniżej
9. PHP »JSON» JavaScript - obudowa węża będzie miało sens; i tak przykręć front
10. PHP »JSON» nie wiesz - snake_case będzie miało sens; i tak przekręć parser
11. Java »JSON» Python - snake_case - zobacz problem Java poniżej
12. Java »JSON» PHP - snake_case - zobacz problem Java poniżej
13. Java »JSON» Java - camelCase - jednogłośnie
14. Java »JSON» JavaScript - camelCase - jednogłośnie
15. Java »JSON» nie wiesz - camelCase ma sens; i tak przekręć parser
16. JavaScript »JSON» Python - snake_case będzie miało sens; i tak przykręć front
17. JavaScript »JSON» PHP - snake_case będzie miało sens; i tak przykręć front
18. JavaScript »JSON» Java - camelCase - jednogłośnie
19. JavaScript »JSON» JavaScript - camelCase - oryginalny

Problem z Javą

snake_case nadal będzie miał sens dla osób z wpisami Java, ponieważ istniejące biblioteki JSON dla Java używają tylko metod dostępu do kluczy zamiast standardowego dot.syntax . Oznacza to, że Java nie zaszkodziłoby tak bardzo dostępowi do kluczy snake_cased w porównaniu z innym językiem programowania, który może wykonywać dot.syntax .

Przykład pakietu Javaorg.json

JsonObject.getString("snake_cased_key")

Przykład pakietu Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Niektóre rzeczywiste wdrożenia

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

Wnioski

Wybór odpowiedniej konwencji nazewnictwa JSON dla implementacji JSON zależy od stosu technologii. Są przypadki, w których można użyć snake_case , camelCase lub innej konwencji nazewnictwa.

Inną rzeczą do rozważenia jest waga, jaką należy przypisać generatorowi JSON w porównaniu z parserem JSON i / lub JavaScriptem frontonu. Zasadniczo większą wagę należy położyć na stronie generatora JSON niż po stronie parsera JSON. Wynika to z faktu, że logika biznesowa zwykle znajduje się po stronie generatora JSON.

Ponadto, jeśli strona parsera JSON jest nieznana, możesz zadeklarować, co kiedykolwiek będzie dla ciebie działać.

Szczególnie w przypadku NodeJS, jeśli pracuję z bazami danych, a moje nazwy pól są rozdzielone podkreśleniem, używam ich również w kluczach struct.

Wynika to z faktu, że pola db mają wiele akronimów / skrótów, więc coś takiego jak appSNSInterfaceRRTest wygląda nieco niechlujnie, ale app_sns_interface_rr_test jest ładniejszy.

W Javascript zmienne są wszystkie camelCase, a nazwy klas (konstruktorów) to ProperCase, więc zobaczysz coś podobnego

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

lub

generalLedgerTask = new GeneralLedgerTask( devTask );

I oczywiście w JSON klucze / ciągi znaków są zawinięte w podwójne cudzysłowy, ale wtedy po prostu używasz JSON.stringify i przekazujesz obiekty JS, więc nie musisz się o to martwić.

Walczyłem z tym trochę, dopóki nie znalazłem tego szczęśliwego medium między konwencjami nazewnictwa JSON i JS.

Wydaje się, że istnieje wystarczająca różnorodność, że ludzie robią wszystko, aby umożliwić konwersję ze wszystkich konwencji na inne: http://www.cowtowncoder.com/blog/archives/cat_json.html

W szczególności wspomniany parser Jackson JSON woli bean_naming.

Myślę, że JSON nie ma oficjalnej konwencji nazewnictwa, ale możesz śledzić liderów branży, aby zobaczyć, jak to działa.

Google, która jest jedną z największych firm informatycznych na świecie, ma przewodnik w stylu JSON: https://google.github.io/styleguide/jsoncstyleguide.xml

Korzystając z tego, możesz znaleźć przewodnik po innych stylach, który Google definiuje, tutaj: https://github.com/google/styleguide

Jak stwierdzili inni, nie ma standardu, więc powinieneś sam go wybrać. W tym celu należy wziąć pod uwagę kilka rzeczy:

1. Jeśli używasz JavaScript do konsumpcji JSON, to użycie tej samej konwencji nazewnictwa dla właściwości w obu zapewni spójność wizualną i możliwe pewne możliwości czystszego ponownego użycia kodu.

2. Małym powodem do uniknięcia przypadku kebab jest to, że łączniki mogą wizualnie kolidować ze -znakami wyświetlanymi w wartościach.

   {
     "bank-balance": -10
   }