JSON Naming Convention

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

dontGoPlastic
Редактировал вопрос 25-го ноября 2014 в 11:14
Программирование
json json.net
4-го апреля 2011 в 7:43
29 просмотров
Комментарии к вопросу (5)

В этом документе [Руководство по стилю Google JSON][1] (рекомендации по созданию API JSON в Google)

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

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

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

Пример:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Моя команда следует этой конвенции.

[1]: https://google.github.io/styleguide/jsoncstyleguide.xml?showone = Property_Name_Format # Property_Name_Format

Tho
Редактировал ответ 29-го сентября 2019 в 3:09
Комментарии (10)
Решение

ЕДИНСТВЕННОГО стандарта не существует, но я видел 3 стиля, которые вы упоминаете («Pascal / Microsoft», «Java» («camelCase») и «C» (подчеркивает, «snake_case») - а также, по крайней мере, еще один , кебаб-кейскак longer-name).

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

ОБНОВЛЕНИЕ: мое определение «стандарт» - ЕДИНСТВЕННОЕ соглашение. Поэтому, хотя можно утверждать, что «да, существует много стандартов», для меня существует несколько «Условных конвенций», ни один из которых не является «Стандартом» в целом. Один из них можно считать стандартом для конкретной платформы, но, учитывая, что JSON используется для взаимодействия между платформами, что может иметь или не иметь большого смысла.

StaxMan
Редактировал ответ 9-го декабря 2016 в 11:20
Комментарии (6)

Premise

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

Движущиеся факторы

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

  1. Программирование языка для генерации JSON
  • Python - snake_case
  • PHP - snake_case
  • Ява - CamelCase
  • JavaScript - camelCase
  1. Сам JSON не имеет стандартного именования ключей
  2. Программирование языка для анализа JSON
  • Python - snake_case
  • PHP - snake_case
  • Ява - CamelCase
  • JavaScript - camelCase

Смешать компоненты

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

Проблема Java

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

Пример для Java org.json package

JsonObject.getString ("snake_cased_key")

Пример для Java's com.google.gson package

JsonElement.getAsString ("snake_cased_key")

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

Выводы

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

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

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

Abel Callejo
Редактировал ответ 27-го сентября 2019 в 7:09
Комментарии (21)

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

Это связано с тем, что поля 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, называющими соглашения.

Комментарии (2)

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

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

Комментарии (1)

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

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

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

Комментарии (0)

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

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

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

    {
  «банковский баланс»: -10
}
moderatemisbehaviour
Редактировал ответ 30-го июля 2018 в 3:38
Комментарии (1)