JSONキーでハイフンを使用することは悪い習慣ですか？

ハイフン（ケバブケース）を使用するJSONキーへのアクセスに関する多くの質問が表示されますが、今ではキーにキャメルケースまたはsnake_caseを使用するべきかどうか疑問に思っています。言語間で移植すると、ハイフンが複雑なマッピングを作成することもあります。一部のJSONデシリアライズライブラリがこれらのキーをcamelCaseスタイルに変換するのを見てきました。

例：

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

対

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

有効なUTF-8であり、コードポイントが含まれていない限り、JSONキーとして何でも使用できます。選択したプログラミング言語でキーを文字列として表すことができれば便利です。同じ文字列の異なるUnicode表現を使用しないことをお勧めします（たとえば、「Ä」は1つまたは2つのコードポイントとして記述されます）。

コメントを読む：JSON辞書のキーと一致するインスタンス変数を持つクラスを作成しようとする人がいるようです。もちろん、COBOLを記述しない限り、キーが「何らかの値」の場合は機能しません。これは見当違いです。私は自分が望む方法で設計されたモデルクラスを持っています。JSONは、モデルクラスを埋めるために使用されます。私は、サーバーの連中は、キーのために使用することを決めたとの中にそれを置くものは何でも取るよ、私のモデルオブジェクト。

多くのJSONシリアル化システムがあり、それらが統合する言語での使用に適さないフィールド名間のマッピングを処理する以上の能力があります。ほとんどの場合、それらは使用するのが難しくなく、ほんの少しの追加の労力しか必要としません。理想的な世界では必要はありませんが、APIがすでにダッシュを使用している場合は、ダッシュを変更することで病気よりも治療が悪化します。また、特定の言語、特にLISPに基づく言語では、ダッシュの使用が最も一般的なスタイルであるため、APIのコンシューマーには、別の形式ではなくダッシュを喜んで表示する少数派がいる可能性があります。

業界でしばらく時間を過ごし、いくつかのシステムで作業した後。JSONキーのベストプラクティスや適切な大文字小文字の区別はないと思います。書式設定（ケーシング/コードスタイルなど）の最も重要な側面は、一貫性とチームの採用です。

コードベースが断片化されており、一貫性がない場合は、チームとして会合し、一貫したスタイルについて合意してから、フォーマットをまとめて監視します。