Плохо ли использовать дефисы в ключах JSON?

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

Пример:

var something = {
  "some-value": 'thing'
}

var something = {
  "someValue": 'thing',
  "some_other_value": 'thing_two'
}

— Мэтт Оахака
источник

REST ничего не говорит о форматах полезной нагрузки.

— Эрик Стейн

Почему вы используете kebab-case в JSON? Люди обычно используют camelCase для JSON, потому что всегда полезно следовать соглашениям об именах среды программирования, а стандартным является использование camelCase для переменных в JavaScript. Хотя я предполагаю, что вы используете JSON для взаимодействия с JavaScript.

— Alternatex

Я вижу, что вопрос помечен javascript, но сам вопрос, похоже, касается API между различными языками / библиотеками. Если вас интересует JavaScript, обратите внимание, что точечная нотация не работает с дефисами.

— Изката

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

— JacquesB

@Alternatex: +1 для "шашлыка" :-)

— gnasher729

Ответы:

Вы можете использовать что угодно в качестве ключей JSON, если это действительно UTF-8, не содержит нулевых кодовых точек, и было бы полезно, если бы вы могли представлять ключ в виде строки на выбранном вами языке программирования. Я мог бы порекомендовать не использовать разные Unicode-представления одной и той же строки (например, «Ä», написанные как одна или две точки кода).

Читая некоторые комментарии: Кажется, некоторые люди пытаются создавать классы с переменными экземпляра, которые соответствуют ключам в словарях JSON. Что, конечно, не работает, если ваш ключ имеет «некоторую ценность», если вы не пишете COBOL. Я думаю, что это неправильно. У меня есть классы моделей, которые разработаны так, как я хочу. JSON просто используется для заполнения классов модели. Я возьму все, что ребята решили использовать для ключей, и вложу в объекты моей модели.

— gnasher729
источник

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

— Ewan

И это действительно так: {"❓": "✅"}

— Виниций Бразилия

Как дефисы предотвращают что-либо? Я получаю словарь, и я могу использовать «некоторый ключ» в качестве ключа, я даже могу использовать «❓» в качестве ключа.

— gnasher729

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

— Жюль
источник

Я буду голосовать как можно скорее, я нашел в этом понимание, спасибо.

— Мэтт Оахака

Проведя некоторое время в отрасли и проработав несколько систем. Я не думаю, что есть лучшая практика или надлежащий корпус для ключей JSON. Наиболее важным аспектом любого форматирования (корпус / стиль кода / и т. Д.) Является последовательность и принятие команды.

Если кодовая база фрагментирована и непоследовательна, соберите команду и договоритесь о едином стиле, а затем коллективно контролируйте форматирование.

— Мэтт Оахака
источник