Соглашение об именах JSON

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

7 ответов


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

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

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


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

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

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

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

пример:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

наша команда использует настоящую конвенцию.


помещения

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

факторы

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

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

    • Python-snake_case
    • PHP-snake_case
    • Java - camelCase
    • JavaScript-camelCase
  2. сам JSON не имеет стандартного именования ключей

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

    • Python-snake_case
    • PHP-snake_case
    • Java-camelCase
    • JavaScript-camelCase

Mix матч компоненты

  1. Python "JSON"Python - snake_case
  2. Python "JSON"PHP - snake_case
  3. Python "JSON"Java - snake_case или camelCase
  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 или camelCase
  9. PHP "JSON"JavaScript - snake_case будет иметь смысл; винт переднего конца в любом случае
  10. PHP "JSON"PHP - snake_case
  11. PHP "JSON" вы не знаете -snake_case будет иметь смысл; винт парсер в любом случае
  12. Java "JSON"Python - camelCase или snake_case
  13. Java "JSON"PHP - camelCase или snake_case
  14. Java "JSON"Java - camelCase
  15. Java "JSON"JavaScript - camelCase
  16. Java "JSON" вы не знаете -camelCase будет иметь смысл; винт парсер в любом случае
  17. JavaScript "JSON"Python - snake_case будет иметь смысл; винт переднего конца в любом случае
  18. JavaScript "JSON"PHP - snake_case будет иметь смысл; винт переднего конца в любом случае
  19. JavaScript "JSON"Java - camelCase
  20. JavaScript "JSON"JavaScript - camelCase

некоторые фактические реализации

выводы

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

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

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


особенно для меня на 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
    }