在JSON密钥中使用连字符是不好的做法吗？

我看到很多问题都与访问使用连字符（kebab-case）的JSON密钥有关，但是现在我发现自己想知道应该在我的密钥中坚持使用camelCase还是snake_case。我知道连字符在语言之间移植时也会产生复杂的映射。我已经看到一些JSON反序列化库将这些键转换为camelCase样式。

例：

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

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

— 马特·瓦哈卡（Matt Oaxaca）
source

REST对于有效负载格式无话可说。

— 埃里克·斯坦

为什么在JSON中使用kebab-case？人们通常将camelCase用于JSON，因为遵循编程环境的命名约定始终是一种好习惯，而对JavaScript中的变量使用camelCase则是一种标准实践。尽管我假设您正在使用JSON与JavaScript进行通信。

— Alternatex

我看到问题是用javascript标记的，但问题本身似乎是关于不同语言/库之间的API。如果您担心使用javascript，请注意点号不适用于连字符。

— 伊兹卡塔'16

这实际上不是一个坏习惯，因为JSON与语言无关，因此不应受任何特定语言的语法的约束。就是说，仅使用字母数字字符是有意义的，因为这可以直接映射到所有主流语言中的标识符，因此这将导致最少的映射麻烦。

— JacquesB '16

@Alternatex：“ kebab-case”为+1 ：-)

— gnasher729

Answers:

您可以使用任何东西作为JSON密钥，只要它是有效的UTF-8，且不包含零代码点，并且如果您可以使用所选的编程语言将密钥表示为字符串，这将非常有用。我可能建议不要对同一字符串使用不同的Unicode表示形式（例如，作为一个或两个代码点编写的“Ä”）。

阅读一些评论：似乎有人尝试使用实例变量创建与JSON字典中的键匹配的类。除非您编写COBOL，否则如果您的键是“某些值”，那么哪一个当然不起作用。我认为这是错误的。我有按照我想要的方式设计的模型类。JSON仅用于填充模型类。我会采取任何服务器人员决定使用的钥匙，并把它变成我的模型对象。

— gnasher729
source

力求您解决您的消费程序如何访问json键的问题。通常，这是通过将json解析为对象来完成的。使用连字号或其他防止这种情况出现的字符只会使您的消费者度过难关

— Ewan

这是有效的：{“❓”：“✅”}

— Vinicius Brasil

连字符如何防止任何事情？我得到一本字典，并且可以使用“ some-key”作为键，甚至可以使用“❓”作为键。

— gnasher729

大量的JSON序列化系统不仅仅能够处理字段名称之间的映射，而且不适合与它们集成的语言一起使用。在大多数情况下，它们并不难使用，只需要一点点额外的努力。在理想的世界中，您不必这样做，但是如果您的API已经使用破折号，那么更改它的疗效将胜于疾病。还要注意，在某些语言中，尤其是基于LISP的语言中，使用破折号是最常见的样式，因此您的API使用者中可能有一个沉默的少数，他们很乐于看到破折号而不是其他格式。

— 朱尔斯
source

我将尽快对此投票进行投票，谢谢。

— 马特·瓦哈卡

在行业中花了一些时间并工作了一些系统之后。我认为JSON键没有最佳实践或适当的大小写。任何格式（外壳/代码样式/等）中最重要的方面是一致性和团队采用率。

如果代码库分散且不一致，请作为一个团队开会并商定一致的样式，然后共同负责格式化。

— 马特·瓦哈卡（Matt Oaxaca）
source