Есть ли стандарт для именования JSON? Я вижу большинство примеров, использующих все строчные буквы, разделенные подчеркиванием (lower_case). Но вы можете использовать PascalCase или camelCase?
Мне было любопытно, что выбрали некоторые лидеры отрасли. API Twitter и Facebook используют snake_case, в то время как Microsoft и Google используют camelCase.
Джастин
2
@ Просто потому, что Twitter использует Ruby, а Facebook использует PHP. Ruby и PHP находятся в snake_case. Microsoft и Google хорошо используют C / .NET и Java соответственно. О, это верно. Net и Java в CamelCase, может быть. Это все о соглашениях языков программирования
Абель
1
Стандартов не существует, но соглашение, похоже, заключается в использовании стандарта технологии принимающей системы.
Мартин
1
Все правильно, в JSON нет строгого соглашения для имен / ключей. Тем не менее, я настоятельно рекомендую избегать использования kebab-case, поскольку к нему нельзя получить доступ через нотацию (.) В javascript, и к нему нужно обращаться с помощью нотации array [], что я считаю утомительным.
Саураб
2
Закрыто как прежде всего основанное на мнении? ФП спрашивал факты о возможностях / ограничениях формата, а не о чьем-либо мнении. Он сказал «можешь», а не «должен». Возможно, ОП не достаточно четко сформулировал это для этих пяти человек, но вам нужно иметь довольно слабое понимание чтения, чтобы не понимать, о чем он спрашивает.
динамический
Ответы:
251
Единого стандарта не существует, но я видел 3 стиля, о которых вы упомянули («Pascal / Microsoft», «Java» ( camelCase) и «C» (подчеркивание snake_case)), а также, по крайней мере, еще один, kebab-caseнапример longer-name).
Похоже, что в основном это зависит от того, что имели разработчики данной службы; те, у кого есть опыт работы с языком c / c ++ (или языки, использующие аналогичное именование, включающее множество языков сценариев, ruby и т. д.), часто выбирают вариант подчеркивания; и отдыхать аналогично (Java против .NET). Библиотека Джексона, которая упоминалась, например, предполагает соглашение об именовании Java-бинов ( camelCase)
ОБНОВЛЕНИЕ: мое определение «стандарт» - ЕДИНОЕ соглашение. Таким образом, хотя можно утверждать, что «да, есть много стандартов», для меня существует множество Naming Conventions, но ни один из них не является «общим» стандартом в целом. Один из них можно считать стандартом для конкретной платформы, но, учитывая, что JSON используется для взаимодействия между платформами, которые могут иметь или не иметь большого смысла.
Важно придерживаться опыта разработчиков, но JSON придерживается стандарта Javascript. Ваше первое утверждение не совсем верно. Но определенно придерживайтесь правил именования вашей команды.
Анубиан Нуб
8
Было бы интересно посмотреть некоторые статистические данные, поскольку между людьми, заявляющими о связи между JSON и Javascript (не просто историческим наследием), существуют постоянные трения, и теми, кто считает, что в настоящее время мало что связывает JSON с Javascript. Я принадлежу к последнему лагерю. Но мне было бы интересно узнать относительные образцы использования.
StaxMan
@StaxMan C # в большинстве случаев использует PascalCase, а не camelCase.
ArtOfCode
@ArtOfCode да. Какова ваша позиция? (также паскаль иногда называют «верхним верблюжьим регистром»)
StaxMan
@StaxMan, не могли бы вы обновить свой ответ, чтобы включить упоминание о Руководстве по стилю Googles
По-видимому, Google изменил руководящие принципы, больше нечего искать в деле о верблюде или начинать с буквы, _ или $ в документе ...
TheEye
32
@TheEye Это все еще там, вам просто нужно нажать на выпадающий список.
gdw2
5
Хороший глаз, @ gdw2. Для других людей в будущем, если вы нажмете кнопку со стрелкой Property Name Guidelines->Property Name Format->Choose meaningful property names..
Panzercrisis
3
Может кто-нибудь объяснить, почему и когда вы использовали бы подчеркивание для префикса имени свойства? Ссылка будет полезна, а не просто мнение.
Шон Гловер,
4
цитирование Google не является правильным ответом. они просто поддерживают определенную конвенцию / директиву, и это выглядит как Java, так как они довольно ориентированы на Java.
snake_case все еще будет иметь смысл для тех, у кого есть записи Java, потому что существующие библиотеки JSON для Java используют только методы для доступа к ключам вместо стандартного dot.syntax . Это означает, что Java не сильно повредит доступу к ключам snake_cased по сравнению с другим языком программирования, который может использовать dot.syntax .
Выбор правильного соглашения об именовании JSON для вашей реализации JSON зависит от вашего технологического стека. Есть случаи, когда можно использовать snake_case , camelCase или любое другое соглашение об именах.
Еще одна вещь, которую следует учитывать, - это вес, который нужно поместить в JSON-генератор против JSON-парсера и / или внешнего JavaScript. В общем, больший вес следует уделять стороне JSON-генератора, а не стороне JSON-парсера. Это связано с тем, что бизнес-логика обычно находится на стороне генератора JSON.
Также, если сторона JSON-парсера неизвестна, вы можете объявить, что когда-либо может работать для вас.
@stoft это, вероятно, потому что они также следовали соглашению schema.org. Начало ключа с заглавной буквы означает, что это словарный запас. Запуск ключа строчной буквой означает, что это словарный запас.
Абель Каллехо
2
Я не согласен с этими идеями просто потому, что бэкэнд Python> Java-интерфейс должен быть camelCase, но затем вы добавляете интерфейс Python и получаете скомпрометированный бэкэнд и один веб-интерфейс. Должно быть так, как это делает бэкэнд по «стандарту». В любом случае парсерам внешнего интерфейса легче адаптироваться
Bojan Kogoj,
2
Меня беспокоит то, что есть ссылка на стек «вашей технологии». Производитель JSON, особенно если его обслуживает HTTP-сервер, не должен знать, кто или что его использует, и по каким причинам. Если JSON используется как метод связи между многими производителями и потребителями, то технологический стек производителя не должен рассматриваться.
Робби Уэрхэм
1
@RobbieWareham Я как-то согласен с этим. Дело в том, что «по стандартам» не существует официального соглашения об именах. Таким образом, с этим, возможно, следует выбрать «де-факто», что посмотреть на стек технологий. Я думаю, что поиск в стеке технологий - лучший путь. Посмотрите на facebook, они исторически соблюдали JavaScript и использовали snakeCase? Неа! Они решили придерживаться PHP snake_case.
Абель Каллехо
18
В частности, для меня на NodeJS, если я работаю с базами данных и имена моих полей разделены подчеркиванием, я также использую их в ключах структуры.
Это связано с тем, что в полях базы данных много аббревиатур / аббревиатур, поэтому что-то вроде appSNSInterfaceRRTest выглядит немного беспорядочно, а app_sns_interface_rr_test приятнее.
В Javascript все переменные являются camelCase, а имена классов (конструкторы) - ProperCase, так что вы увидите что-то вроде
var devTask ={
task_id:120,
store_id:2118,
task_name:'generalLedger'};
И, конечно, в JSON ключи / строки заключаются в двойные кавычки, но тогда вы просто используете JSON.stringify и передаете объекты JS, так что вам не нужно об этом беспокоиться.
Я немного боролся с этим, пока не нашел эту удачную среду между соглашениями об именах JSON и JS.
тоже самое. Получение JSON с snake_case на клиенте Android выглядит неловко !! Кроме того, база данных не различает регистр имен столбцов, поэтому snake_case кажется лучшим для базы данных.
Мифический
@mythicalcoder JSON в Java не является внутренним по своей сути. Java использует только внешние пакеты для разбора Java , например org.json, gson. Получение данных snake_case не так больно, как так ...JSONObject.get('snake_case_key_here')
Как утверждают другие, стандарта нет, поэтому вы должны выбрать его самостоятельно. Вот несколько вещей, которые следует учитывать при этом:
Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих случаях обеспечит визуальную согласованность и, возможно, некоторые возможности для более чистого повторного использования кода.
Небольшой причиной, по которой следует избегать использования кебаба, является то, что дефисы могут визуально конфликтовать с -символами, которые появляются в значениях.
Ответы:
Единого стандарта не существует, но я видел 3 стиля, о которых вы упомянули («Pascal / Microsoft», «Java» (
camelCase) и «C» (подчеркиваниеsnake_case)), а также, по крайней мере, еще один,kebab-caseнапримерlonger-name).Похоже, что в основном это зависит от того, что имели разработчики данной службы; те, у кого есть опыт работы с языком c / c ++ (или языки, использующие аналогичное именование, включающее множество языков сценариев, ruby и т. д.), часто выбирают вариант подчеркивания; и отдыхать аналогично (Java против .NET). Библиотека Джексона, которая упоминалась, например, предполагает соглашение об именовании Java-бинов (
camelCase)ОБНОВЛЕНИЕ: мое определение «стандарт» - ЕДИНОЕ соглашение. Таким образом, хотя можно утверждать, что «да, есть много стандартов», для меня существует множество
Naming Conventions, но ни один из них не является «общим» стандартом в целом. Один из них можно считать стандартом для конкретной платформы, но, учитывая, что JSON используется для взаимодействия между платформами, которые могут иметь или не иметь большого смысла.источник
В этом документе Руководство по стилю Google JSON (рекомендации по созданию API-интерфейсов JSON в Google),
Он рекомендует, чтобы:
Имена свойств должны быть в CamelCased , ASCII-строки.
Первый символ должен быть буквой, подчеркиванием (_) или знаком доллара ($).
Пример:
Моя команда следует этому соглашению.
источник
Property Name Guidelines->Property Name Format->Choose meaningful property names..посылка
В JSON нет стандартного именования ключей . Согласно разделу Объекты спецификации:
Что означает, что camelCase или snake_case должны работать нормально.
Факторы вождения
Введение соглашения об именовании JSON очень запутанно. Однако это легко понять, если разбить его на компоненты.
Язык программирования для генерации JSON
Сам JSON не имеет стандартного именования ключей
Язык программирования для разбора JSON
Смешивать и подбирать компоненты
Проблема с Java
snake_case все еще будет иметь смысл для тех, у кого есть записи Java, потому что существующие библиотеки JSON для Java используют только методы для доступа к ключам вместо стандартного dot.syntax . Это означает, что Java не сильно повредит доступу к ключам snake_cased по сравнению с другим языком программирования, который может использовать dot.syntax .
Пример для пакета Java
org.jsonJsonObject.getString("snake_cased_key")Пример для пакета Java
com.google.gsonJsonElement.getAsString("snake_cased_key")Некоторые актуальные реализации
Выводы
Выбор правильного соглашения об именовании JSON для вашей реализации JSON зависит от вашего технологического стека. Есть случаи, когда можно использовать snake_case , camelCase или любое другое соглашение об именах.
Еще одна вещь, которую следует учитывать, - это вес, который нужно поместить в JSON-генератор против JSON-парсера и / или внешнего JavaScript. В общем, больший вес следует уделять стороне JSON-генератора, а не стороне JSON-парсера. Это связано с тем, что бизнес-логика обычно находится на стороне генератора JSON.
Также, если сторона JSON-парсера неизвестна, вы можете объявить, что когда-либо может работать для вас.
источник
"Person":не camelCase :)В частности, для меня на NodeJS, если я работаю с базами данных и имена моих полей разделены подчеркиванием, я также использую их в ключах структуры.
Это связано с тем, что в полях базы данных много аббревиатур / аббревиатур, поэтому что-то вроде appSNSInterfaceRRTest выглядит немного беспорядочно, а app_sns_interface_rr_test приятнее.
В Javascript все переменные являются camelCase, а имена классов (конструкторы) - ProperCase, так что вы увидите что-то вроде
или
И, конечно, в JSON ключи / строки заключаются в двойные кавычки, но тогда вы просто используете JSON.stringify и передаете объекты JS, так что вам не нужно об этом беспокоиться.
Я немного боролся с этим, пока не нашел эту удачную среду между соглашениями об именах JSON и JS.
источник
org.json,gson. Получение данных snake_case не так больно, как так ...JSONObject.get('snake_case_key_here')Кажется, что есть достаточно вариантов, чтобы люди старались изо всех сил разрешить переход из всех соглашений в другие: http://www.cowtowncoder.com/blog/archives/cat_json.html
Примечательно, что упомянутый парсер Jackson JSON предпочитает
bean_naming.источник
beanNaming.Я думаю, что в JSON нет официального соглашения об именах, но вы можете проследить за некоторыми лидерами отрасли, чтобы увидеть, как это работает.
Google, которая является одной из крупнейших ИТ-компаний в мире, имеет руководство по стилю JSON: https://google.github.io/styleguide/jsoncstyleguide.xml
Воспользовавшись этим, вы можете найти руководство по другим стилям, которое определяет Google, здесь: https://github.com/google/styleguide
источник
Как утверждают другие, стандарта нет, поэтому вы должны выбрать его самостоятельно. Вот несколько вещей, которые следует учитывать при этом:
Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих случаях обеспечит визуальную согласованность и, возможно, некоторые возможности для более чистого повторного использования кода.
Небольшой причиной, по которой следует избегать использования кебаба, является то, что дефисы могут визуально конфликтовать с
-символами, которые появляются в значениях.источник