Соглашение об именовании JSON [закрыто]

Есть ли стандарт для именования JSON? Я вижу большинство примеров, использующих все строчные буквы, разделенные подчеркиванием (lower_case). Но вы можете использовать PascalCase или camelCase?

Единого стандарта не существует, но я видел 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),

Он рекомендует, чтобы:

1. Имена свойств должны быть в CamelCased , ASCII-строки.

2. Первый символ должен быть буквой, подчеркиванием (_) или знаком доллара ($).

Пример:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Моя команда следует этому соглашению.

посылка

В JSON нет стандартного именования ключей . Согласно разделу Объекты спецификации:

Синтаксис JSON не накладывает никаких ограничений на строки, используемые в качестве имен, ...

Что означает, что camelCase или snake_case должны работать нормально.

Факторы вождения

Введение соглашения об именовании JSON очень запутанно. Однако это легко понять, если разбить его на компоненты.

1. Язык программирования для генерации JSON

   • Python - случай змеи
   • PHP - случай змеи
   • Java - camelCase
   • JavaScript - camelCase

2. Сам JSON не имеет стандартного именования ключей

3. Язык программирования для разбора JSON

   • Python - случай змеи
   • PHP - случай змеи
   • Java - camelCase
   • JavaScript - camelCase

Смешивать и подбирать компоненты

1. Python »JSON» Python - случай змеи - единодушный
2. Python »JSON» PHP - snake_case - единодушный
3. Python »JSON» Java - snake_case - посмотрите проблему Java ниже
4. Python »JSON» JavaScript - snake_case будет иметь смысл; в любом случае прикрутить переднюю часть
5. Python »JSON» вы не знаете - snake_case будет иметь смысл; винт парсер все равно
6. PHP »JSON» Python - snake_case - единодушный
7. PHP »JSON» PHP - snake_case - единодушный
8. PHP »JSON» Java - snake_case - посмотрите проблему Java ниже
9. PHP »JSON» JavaScript - snake_case будет иметь смысл; в любом случае прикрутить переднюю часть
10. PHP »JSON» вы не знаете - snake_case будет иметь смысл; винт парсер все равно
11. Java »JSON» Python - snake_case - посмотрите проблему Java ниже
12. Java »JSON» PHP - snake_case - посмотрите проблему Java ниже
13. Java »JSON» Java - camelCase - единогласно
14. Java »JSON» JavaScript - camelCase - единогласно
15. Java »JSON» вы не знаете - camelCase будет иметь смысл; винт парсер все равно
16. JavaScript »JSON» Python - snake_case будет иметь смысл; в любом случае прикрутить переднюю часть
17. JavaScript »JSON» PHP - snake_case будет иметь смысл; в любом случае прикрутить переднюю часть
18. JavaScript »JSON» Java - camelCase - единогласно
19. JavaScript »JSON» JavaScript - camelCase - Оригинальный

Проблема с Java

snake_case все еще будет иметь смысл для тех, у кого есть записи Java, потому что существующие библиотеки JSON для Java используют только методы для доступа к ключам вместо стандартного dot.syntax . Это означает, что Java не сильно повредит доступу к ключам snake_cased по сравнению с другим языком программирования, который может использовать dot.syntax .

Пример для пакета Javaorg.json

JsonObject.getString("snake_cased_key")

Пример для пакета Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Некоторые актуальные реализации

• Google Maps JavaScript API - camelCased
• JavaScript API Facebook - snake_cased
• Веб-сервисы Amazon - snake_cased & camelCased
• API Twitter - snake_cased
• JSON-LD - CamelCased & ProperCamelCased

Выводы

Выбор правильного соглашения об именовании JSON для вашей реализации JSON зависит от вашего технологического стека. Есть случаи, когда можно использовать snake_case , camelCase или любое другое соглашение об именах.

Еще одна вещь, которую следует учитывать, - это вес, который нужно поместить в JSON-генератор против JSON-парсера и / или внешнего JavaScript. В общем, больший вес следует уделять стороне JSON-генератора, а не стороне JSON-парсера. Это связано с тем, что бизнес-логика обычно находится на стороне генератора JSON.

Также, если сторона JSON-парсера неизвестна, вы можете объявить, что когда-либо может работать для вас.

В частности, для меня на NodeJS, если я работаю с базами данных и имена моих полей разделены подчеркиванием, я также использую их в ключах структуры.

Это связано с тем, что в полях базы данных много аббревиатур / аббревиатур, поэтому что-то вроде appSNSInterfaceRRTest выглядит немного беспорядочно, а app_sns_interface_rr_test приятнее.

В Javascript все переменные являются camelCase, а имена классов (конструкторы) - ProperCase, так что вы увидите что-то вроде

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

или

generalLedgerTask = new GeneralLedgerTask( devTask );

И, конечно, в JSON ключи / строки заключаются в двойные кавычки, но тогда вы просто используете JSON.stringify и передаете объекты JS, так что вам не нужно об этом беспокоиться.

Я немного боролся с этим, пока не нашел эту удачную среду между соглашениями об именах JSON и JS.

Кажется, что есть достаточно вариантов, чтобы люди старались изо всех сил разрешить переход из всех соглашений в другие: http://www.cowtowncoder.com/blog/archives/cat_json.html

Примечательно, что упомянутый парсер Jackson JSON предпочитает bean_naming.

Я думаю, что в JSON нет официального соглашения об именах, но вы можете проследить за некоторыми лидерами отрасли, чтобы увидеть, как это работает.

Google, которая является одной из крупнейших ИТ-компаний в мире, имеет руководство по стилю JSON: https://google.github.io/styleguide/jsoncstyleguide.xml

Воспользовавшись этим, вы можете найти руководство по другим стилям, которое определяет Google, здесь: https://github.com/google/styleguide

Как утверждают другие, стандарта нет, поэтому вы должны выбрать его самостоятельно. Вот несколько вещей, которые следует учитывать при этом:

1. Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих случаях обеспечит визуальную согласованность и, возможно, некоторые возможности для более чистого повторного использования кода.

2. Небольшой причиной, по которой следует избегать использования кебаба, является то, что дефисы могут визуально конфликтовать с -символами, которые появляются в значениях.

   {
     "bank-balance": -10
   }