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?
Byłem ciekawy, co wybrali niektórzy liderzy branży. Interfejsy API Twittera i Facebooka używają snake_case, podczas gdy Microsoft i Google używają camelCase.
Justin
2
@Justin, ponieważ Twitter używa Ruby, a Facebook używa PHP. Ruby i PHP zajmują się snake_case. Microsoft i Google dobrze używają odpowiednio C / .NET i Java. Och, właśnie tak. Net i Java mogą być w camelCase. Chodzi o konwencje języków programowania
Abel Callejo,
1
Nie ma standardu, ale konwencją wydaje się być stosowanie standardu technologii systemu odbiorczego.
Martin z Hessle,
1
Wszystkie są poprawne, nie ma rygorystycznej konwencji dla nazw / kluczy w JSON. Chociaż zdecydowanie zalecam unikanie kebab-case, ponieważ nie można uzyskać do niego dostępu za pomocą notacji kropkowej (.) W javascript i należy uzyskać do niej dostęp za pomocą notacji tablicowej [], co moim zdaniem jest uciążliwe.
saurabh
2
Zamknięte jako oparte głównie na opiniach? OP poprosił o fakty dotyczące możliwości / ograniczeń formatu, a nie o czyjąkolwiek opinię. Powiedział „możesz”, a nie „powinieneś”. Być może OP nie napisał tego wystarczająco jasno dla tych pięciu osób, ale musiałbyś mieć słabe rozumienie czytania, aby nie zrozumieć, o co prosi.
dynamichael
Odpowiedzi:
251
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.
Trzymanie się tła deweloperów jest ważne, ale JSON trzyma się standardu Javascript. Twoje pierwsze stwierdzenie nie jest całkiem poprawne. Ale zdecydowanie trzymaj się konwencji nazewnictwa twojego zespołu.
Anubian Noob
8
Interesujące byłoby zobaczenie niektórych statystyk, ponieważ istnieje ciągłe tarcie między ludźmi, którzy twierdzą, że istnieje połączenie między JSON a JavaScript (poza zwykłym dziedzictwem historycznym), a tymi, którzy myślą, że niewiele obecnie łączy JSON z Javascriptem. Należę do tego ostatniego obozu. Byłbym jednak zainteresowany poznaniem względnych wzorców użytkowania.
StaxMan,
@StaxMan C # w większości przypadków używa PascalCase, a nie camelCase.
ArtOfCode,
@ArtOfCode tak. O co ci chodzi? (również przypadek
pascala
@StaxMan zastanów się nad zaktualizowaniem swojej odpowiedzi, aby zawierała wzmiankę o Przewodniku po stylu Google
Najwyraźniej Google zmieniło wytyczne, nic nie można znaleźć na temat wielbłąda lub zaczynając od litery, _ lub $ w dokumencie ...
TheEye
32
@ TheEye Nadal tam jest, wystarczy kliknąć menu rozwijane.
gdw2,
5
Dobre oko, @ gdw2. Dla innych osób w przyszłości będzie to możliwe, jeśli klikniesz przycisk strzałki obok Property Name Guidelines->Property Name Format->Choose meaningful property names..
Panzercrisis,
3
Czy ktoś może wyjaśnić, dlaczego i kiedy użyjesz podkreślenia do prefiksu nazwy właściwości? Przydałoby się odniesienie, a nie tylko opinia.
Sean Glover
4
powoływanie się na Google nie jest odpowiednią odpowiedzią. popierają tylko pewną konwencję / wytyczne i wygląda na to, że Java ma sens, ponieważ są bardzo zorientowani na język Java.
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 .
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ć.
@stoft prawdopodobnie dlatego, że przestrzegali również konwencji schema.org. Rozpoczęcie klucza wielką literą oznacza, że jest to jednostka słownictwa. Rozpoczęcie klawisza małą literą oznacza, że jest to właściwość słownictwa.
Abel Callejo,
2
Nie zgadzam się z tymi pomysłami, po prostu dlatego, że backend Pythona> Frontend Java powinien być camelCase, ale potem dodajesz frontend Pythona i skompromitowałeś backend i jeden frontend. Powinno być tak, jak ma to backend według „standardu”. Parsery frontendu i tak mają łatwiejszą adaptację
Bojan Kogoj
2
Obawiam się tutaj, że istnieje odniesienie do stosu „twojej technologii”. Producent JSON, zwłaszcza jeśli ma być obsługiwany przez serwer HTTP, nie powinien mieć wiedzy o tym, kto go konsumuje ani z jakich powodów. Jeśli JSON jest używany jako metoda komunikacji między wieloma producentami i konsumentami, wówczas stos technologiczny producenta nie powinien być brany pod uwagę.
Robbie Wareham
1
@RobbieWareham Jakoś się z tym zgadzam. Chodzi o to, że „według standardów” nie ma oficjalnej konwencji nazewnictwa. A zatem, może należy wybrać „de facto”, czyli patrzeć na stos technologii. Myślę, że najlepszym sposobem jest zajrzenie do stosu technologii. Spójrz na Facebook, czy historycznie honorowali JavaScript i używali snakeCase? Nie! Zdecydowali się pozostać przy PHP-snake_case.
Abel Callejo
18
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'};
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.
to samo tutaj. Odbieranie JSON z snake_case na kliencie z Androidem wygląda niezręcznie !! Również baza danych nie rozróżnia wielkości liter dla nazw kolumn, więc snake_case wydaje się najlepsza dla bazy danych.
mityczny
@mythicalcoder JSON w Javie nie jest nieodłączny w swoim rdzeniu. Java używa tylko pakiety zewnętrzne do analizowania Java np org.json, gson. Odbieranie danych skrzynki węża nie jest tak bardzo bolesne ...JSONObject.get('snake_case_key_here')
Jak stwierdzili inni, nie ma standardu, więc powinieneś sam go wybrać. W tym celu należy wziąć pod uwagę kilka rzeczy:
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.
Małym powodem do uniknięcia przypadku kebab jest to, że łączniki mogą wizualnie kolidować ze -znakami wyświetlanymi w wartościach.
Odpowiedzi:
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 jedenkebab-case
podobnylonger-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.źródło
W tym dokumencie Przewodnik po stylu Google JSON (zalecenia dotyczące tworzenia interfejsów API JSON w Google),
Zaleca:
Nazwy właściwości muszą być wielbłądami , ciągami ASCII.
Pierwszym znakiem musi być litera, znak podkreślenia (_) lub znak dolara ($).
Przykład:
Mój zespół przestrzega tej konwencji.
źródło
Property Name Guidelines->Property Name Format->Choose meaningful property names.
.Przesłanka
W JSON nie ma standardowego nazewnictwa kluczy . Zgodnie z sekcją Obiekty specyfikacji:
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.
Język programowania do generowania JSON
Sam JSON nie ma standardowej nazwy kluczy
Język programowania do analizy JSON
Dopasuj składniki
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 Java
org.json
JsonObject.getString("snake_cased_key")
Przykład pakietu Java
com.google.gson
JsonElement.getAsString("snake_cased_key")
Niektóre rzeczywiste wdrożenia
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ć.
źródło
"Person":
nie jest camelCase :)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
lub
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.
źródło
org.json
,gson
. Odbieranie danych skrzynki węża nie jest tak bardzo bolesne ...JSONObject.get('snake_case_key_here')
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
.źródło
beanNaming
.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
źródło
Jak stwierdzili inni, nie ma standardu, więc powinieneś sam go wybrać. W tym celu należy wziąć pod uwagę kilka rzeczy:
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.
Małym powodem do uniknięcia przypadku kebab jest to, że łączniki mogą wizualnie kolidować ze
-
znakami wyświetlanymi w wartościach.źródło