Конвенция о присвоении имен JSON

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

Ответ 1

Нет стандарта SINGLE, но я видел три стиля, которые вы упомянули ( "Pascal/Microsoft", "Java" (camelCase) и "C" (подчеркивание, snake_case)), а также в менее чем один, kebab-case как longer-name).

В основном это зависит от того, какие фоновые разработчики этой услуги имели; те, у кого c/С++ background (или языки, которые используют аналогичное именование, включая многие языки сценариев, ruby и т.д.), часто выбирают вариант подчеркивания; и аналогичным образом (Java vs .NET). Библиотека Jackson, о которой упоминалось, например, предполагает соглашение о назначении Java bean (camelCase)

UPDATE: мое определение "стандарт" - это соглашение SINGLE. Поэтому, хотя можно было утверждать: "Да, существует много стандартов", для меня существует несколько Naming Conventions, ни один из которых не является стандартом "Стандарт". Один из них можно считать стандартом для конкретной платформы, но учитывая, что JSON используется для взаимодействия между платформами, которые могут или не могут иметь большого смысла.

Ответ 2

В этом документе Руководство по стилю Google JSON (рекомендации по созданию API-интерфейсов JSON в Google),

Он рекомендует:

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

Пример:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

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

Ответ 3

Предпосылка

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

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

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

Язык программирования для генерации JSON
- Python - случай змеи
- PHP - snake_case
- Java - camelCase
- JavaScript - camelCase
Сам JSON не имеет стандартного именования ключей
Язык программирования для анализа JSON
- Python - случай змеи
- PHP - snake_case
- Java - camelCase
- JavaScript - camelCase

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

Python "JSON" Python - случай змеи - единодушный
Python "JSON" PHP - случай змеи - единодушный
Python "JSON" Java - snake_case - см. проблему с Java ниже
Python "JSON" JavaScript - snake_case будет иметь смысл; в любом случае прикрутите переднюю часть
Python "JSON" вы не знаете - snake_case будет иметь смысл; все равно винт парсер
PHP "JSON" Python - случай змеи - единодушный
PHP "JSON" PHP - случай змеи - единогласно
PHP "JSON" Java - snake_case - см. проблему с Java ниже
PHP "JSON" JavaScript - snake_case будет иметь смысл; в любом случае прикрутите переднюю часть
PHP "JSON" вы не знаете - snake_case будет иметь смысл; все равно винт парсер
Java "JSON" Python - snake_case - см. проблему с Java ниже
Java "JSON" PHP - snake_case - см. проблему с Java ниже
Java "JSON" Java - camelCase
Java "JSON" JavaScript - camelCase
Java "JSON" вы не знаете - camelCase будет иметь смысл; все равно винт парсер
JavaScript "JSON" Python - snake_case будет иметь смысл; в любом случае прикрутите переднюю часть
JavaScript "JSON" PHP - snake_case будет иметь смысл; в любом случае прикрутите переднюю часть
JavaScript "JSON" Java - camelCase - единогласно
JavaScript "JSON" JavaScript - camelCase - единогласно

Проблема с Java

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

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

JsonObject.getString("snake_cased_key")

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

JsonElement.getAsString("snake_cased_key")

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

JavaScript API Карт Google - camelCased
API JavaScript 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-парсера неизвестна, вы можете объявить, что когда-либо может работать для вас.

Ответ 4

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

Это связано с тем, что поля db содержат много аббревиатур/аббревиатур, поэтому что-то вроде 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.

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих случаях обеспечит визуальную согласованность и, возможно, некоторые возможности для более чистого повторного использования кода.
Небольшая причина, чтобы избежать шашлыка случая является то, что дефис может столкнуться визуально - символы, которые появляются в значениях.
```
{
  "bank-balance": -10
}
```