Конвенція про іменування JSON [закрита]

Чи існує стандарт щодо іменування JSON? Я бачу більшість прикладів, використовуючи всі малі регістри, розділені підкресленням (нижній_запис). Але чи можете ви використовувати PascalCase чи camelCase?

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

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

ОНОВЛЕННЯ: моє визначення поняття "стандарт" - це ЄДИННА конвенція. Тож, хоча можна було б стверджувати "так, є багато стандартів", для мене їх багато Naming Conventions, жоден з яких не є "загальним" стандартом. Один з них можна вважати еталоном для конкретної платформи, але враховуючи, що JSON використовується для взаємодії між платформами, яка може мати або не мати особливого сенсу.

У цьому документі Посібник зі стилів Google JSON (рекомендації щодо створення API JSON в Google),

Він рекомендує:

1. Імена властивостей повинні бути camelCrozen , рядки 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 - snake_case - одностайний
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")

Деякі реальні реалізації

• API API Google Maps - camelCased
• Facebook JavaScript API - snake_cased
• Веб-сервіси Amazon - зміїні_місцеві і верблюдиЗакриті
• API API - змія
• JSON-LD - camelCased & ProperCamelCased

Висновки

Вибір правильної умови іменування JSON для вашої реалізації JSON залежить від вашої технології стеку. Є випадки, коли можна використовувати snake_case , camelCase або будь-яку іншу конвенцію про іменування.

Інша річ, яку слід врахувати, - це вага, який слід надати JSON-генератору проти JSON-аналізатора та / або переднього JavaScript. Як правило, більше ваги слід приділяти стороні генератора JSON, а не стороні JSON-аналізатора. Це тому, що бізнес-логіка зазвичай знаходиться на стороні генератора JSON.

Крім того, якщо сторона аналізатора JSON невідома, ви можете заявити, що коли-небудь може працювати для вас.

Примітно для мене на 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.

Здається, що існує достатня кількість варіантів, щоб люди вийшли зі свого шляху, щоб дозволити перехід від усіх конвенцій до інших: 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
   }