Czy złym zwyczajem jest używanie łączników w kluczach JSON?

Widzę wiele pytań dotyczących dostępu do klawiszy JSON, które używają łączników (kebab-case), ale teraz zastanawiam się, czy powinienem po prostu trzymać się camelCase lub snake_case w moich kluczach. Wiem, że łączniki mogą również tworzyć skomplikowane odwzorowania, gdy są przenoszone między językami. Widziałem, jak niektóre biblioteki JSON przekształcają te klucze w styl camelCase.

Przykład:

var something = {
  "some-value": 'thing'
}

var something = {
  "someValue": 'thing',
  "some_other_value": 'thing_two'
}

— Matt Oaxaca
źródło

REST nie ma nic do powiedzenia na temat formatów ładunku.

— Eric Stein

Dlaczego używasz kebab-case w JSON? Ludzie zwykle używają camelCase dla JSON, ponieważ zawsze dobrą praktyką jest przestrzeganie konwencji nazewnictwa środowiska programistycznego i standardową praktyką jest używanie camelCase do zmiennych w JavaScript. Chociaż zakładam, że używasz JSON do komunikowania się za pomocą JavaScript.

— Alternatex

Widzę, że pytanie jest oznaczone javascript, ale samo pytanie wydaje się dotyczyć interfejsu API między różnymi językami / bibliotekami. Jeśli interesujesz się javascript, pamiętaj, że notacja kropkowa nie działa z myślnikami.

— Izkata

Nie jest to naprawdę zła praktyka, ponieważ JSON jest niezależny od języka i dlatego nie powinien być ograniczany przez składnię konkretnego języka. To powiedziawszy, sensowne jest używanie tylko znaków alfanumerycznych, ponieważ może to być mapowane bezpośrednio na identyfikatory we wszystkich językach głównego nurtu, więc doprowadzi to do najmniejszego problemu z mapowaniem.

— JacquesB

@Alternatex: +1 dla „kebab-case” :-)

— gnasher729,

Odpowiedzi:

Możesz używać czegokolwiek jako kluczy JSON, pod warunkiem, że jest to poprawny kod UTF-8, nie zawiera zerowych punktów kodowych i byłoby przydatne, gdybyś mógł reprezentować klucz jako ciąg znaków w wybranym języku programowania. Mogę zalecić, aby nie używać różnych reprezentacji Unicode tego samego łańcucha (na przykład „Ę” zapisanych jako jeden lub dwa punkty kodowe).

Czytanie komentarzy: Wygląda na to, że niektórzy ludzie próbują tworzyć klasy ze zmiennymi instancji, które pasują do kluczy w słownikach JSON. Które oczywiście nie działa, jeśli twój klucz ma „pewną wartość”, chyba że piszesz COBOL. Myślę, że to jest błędne. Mam klasy modeli, które są zaprojektowane tak, jak chcę. JSON służy tylko do wypełnienia klas modeli. Wezmę wszystko, co faceci serwera postanowili wykorzystać do kluczy i umieszczę je w moich obiektach modelu.

— gnasher729
źródło

urg, zadajesz pytanie, w jaki sposób Twój program konsumujący uzyskuje dostęp do kluczy JSON. Zwykle odbywa się to przez parsowanie JSON jako obiektu. Używanie łączników lub innych znaków, które temu zapobiegają, po prostu utrudnia życie konsumentom

— Ewan

I to jest ważne: {"❓": "✅"}

— Vinicius Brasil

Jak łączniki coś zapobiegają? Dostaję słownik i mogę użyć „jakiegoś klucza” jako klucza, mogę nawet użyć „❓” jako klucza.

— gnasher729

Istnieje wiele systemów serializacji JSON, które są w stanie obsłużyć mapowanie między nazwami pól, które nie są odpowiednie do użycia w języku, z którym się integrują. W większości przypadków nie są trudne w użyciu i wymagają tylko odrobiny dodatkowego wysiłku. W idealnym świecie nie musiałbyś tego robić, ale jeśli twój interfejs API już korzysta z myślników, jego zmiana byłaby skuteczniejsza niż choroba. Zauważ też, że używanie myślników jest najbardziej popularnym stylem w niektórych językach, zwłaszcza tych opartych na LISP, więc prawdopodobnie jest cicha mniejszość konsumentów twojego API, którzy chętnie widzą myślniki niż inny format.

— Jules
źródło

Zagłosuję tak szybko, jak to możliwe. Znalazłem wgląd w to, dziękuję.

— Matt Oaxaca

Po spędzeniu czasu w branży i pracy w kilku systemach. Nie sądzę, że istnieje najlepsza praktyka lub odpowiednia obudowa dla kluczy JSON. Najważniejszym aspektem każdego formatowania (obudowa / styl kodu / itp.) Jest spójność i przyjęcie zespołu.

Jeśli podstawa kodu jest rozdrobniona i niespójna, spotkaj się jako zespół i uzgodnij spójny styl, a następnie wspólnie zgrupuj formowanie.

— Matt Oaxaca
źródło