JSON 命名约定（snake_case、camelCase 或 PascalCase）[关闭]

Posted 2023-04-13

【中文标题】JSON 命名约定（snake_case、camelCase 或 PascalCase）[关闭]

【英文标题】：JSON Naming Convention (snake_case, camelCase or PascalCase) [closed]

【发布时间】：2011-07-29 10:43:27

【问题描述】：

JSON 命名是否有标准？我看到大多数示例都使用下划线分隔的全小写，也就是 snake_case，但也可以使用 PascalCase 或 camelCase 吗？

【问题讨论】：

我很好奇一些行业领导者选择了什么。 Twitter 和 Facebook API 使用 snake_case，而 Microsoft 和 Google 使用 camelCase。

@Justin 那是因为 Twitter 使用 Ruby 而 Facebook 使用 php。 Ruby 和 PHP 都进入了 snake_case。微软和谷歌分别很好地使用了 C/.NET 和 Java。哦，是的，.Net 和 Java 可能会使用 camelCase。 It's all about the conventions of the programming languages

没有标准，但约定似乎是使用接收系统的技术标准。

一切都是正确的，JSON 中的名称/键没有严格的约定。不过，我强烈建议避免使用 kebab-case，因为它不能通过 javascript 中的点 (.) 表示法访问，并且必须使用我认为乏味的 array[] 表示法访问。

因主要基于意见而关闭？ OP 是在询问有关格式功能/限制的事实，而不是征求任何人的意见。他说的是“你能”，而不是“你应该”。也许 OP 对这五个人说得不够清楚，但你必须有相当差的阅读理解才能不明白他在问什么。

【参考方案1】：

在本文档Google JSON Style Guide（关于在 Google 构建 JSON API 的建议）中，

建议：

属性名称必须是 camelCased、ASCII 字符串。

第一个字符必须是字母、下划线 (_) 或美元符号 ($)。

例子：

  "thisPropertyIsAnIdentifier": "identifier value"

我的团队在构建 REST API 时始终遵循这一约定。有一些原因：

首先，JSON 约定应该独立于编程语言，因为我们希望我们的 API 保持一致，无论是否有一些 API 使用 camelCase 语言（例如 Java）实现，其他一些 API 使用 snake_case语言（例如 Python）。 另外，我们的大多数客户都是 webapp，所以camelCase 是首选 如果客户更喜欢snake_case，它仍然可以轻松地在snake_case和camelCase之间转换数据（借助库）

但我同意，如果所有应用程序都使用相同类型的语言（例如 snake_case），那么 JSON 约定也应该遵循。

【讨论】：

显然谷歌已经改变了指导方针，在文档中找不到关于驼峰大小写或以字母、_ 或 $ 开头的内容了......

@TheEye 还在，你只需要点击下拉即可。

好眼光，@gdw2。对于未来的其他人，如果你点击Property Name Guidelines->Property Name Format->Choose meaningful property names.的箭头按钮。

引用谷歌并不是一个正确的答案。它们只支持某种约定/准则，并且看起来很有意义，因为它们非常面向 Java。

这里也是热门话题github.com/json-api/json-api/pull/1247

【参考方案2】：

没有 SINGLE 标准，但我见过你提到的 3 种样式（“Pascal/Microsoft”、“Java”（camelCase）和“C”（下划线，snake_case））——以及至少还有一个，kebab-case 就像 longer-name)。

这似乎主要取决于相关服务的后台开发人员拥有什么；具有 c/c++ 背景的人（或采用类似命名的语言，包括许多脚本语言、ruby 等）通常选择下划线变体；并以类似方式休息（Java vs .NET）。例如，提到的 Jackson 库采用 Java bean 命名约定 (camelCase)

更新：我对“标准”的定义是一个单一的约定。因此，虽然有人可以声称“是的，有很多标准”，但对我来说，有多个 Naming Conventions，但总体上没有一个是“The”标准。其中之一可以被视为特定平台的标准，但考虑到 JSON 用于平台之间的互操作性，这可能有意义也可能没有多大意义。

【讨论】：

坚持开发者的背景很重要，但 JSON 坚持 Javascript 标准。您的第一个陈述并不完全正确。但一定要遵守团队的命名约定。

看看一些统计数据会很有趣，因为声称 JSON 和 Javascript 之间存在联系（不仅仅是历史遗产）的人与那些认为目前几乎没有将 JSON 连接到Javascript。我属于后一种阵营。但我有兴趣了解相关的使用模式。

@StaxMan C# 在大多数情况下使用 PascalCase，而不是 camelCase。

@ArtOfCode 是的。你想说啥？ （另外，pascal-case 有时也称为“大驼峰式”）

@StaxMan 您是否会考虑更新您的答案以包括提及 Google 风格指南

【参考方案3】：

ECMA-404

JSON 语法对用作名称的字符串没有任何限制，...

JSON 中的键没有标准命名，camelCase 或 snake_case 应该可以正常工作。

TL;DR

这是我认为大多数开发人员都在使用的拇指规则。

Technology stack	Naming convention	Reason/guide
Python » JSON » Python	snake_case	Unanimous
Python » JSON » PHP	snake_case	Unanimous
Python » JSON » Java	snake_case or camelCase	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Python » JSON » back‑end JavaScript	snake_case or camelCase	Lean on where the business logic resides.
Python » JSON » front‑end JavaScript	snake_case	Screw the front-end anyway
Python » JSON » you do not know	snake_case	Screw the parser anyway
PHP » JSON » Python	snake_case	Unanimous
PHP » JSON » PHP	snake_case	Unanimous
PHP » JSON » Java	snake_case or camelCase	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
PHP » JSON » back‑end JavaScript	snake_case or camelCase	Lean on where the business logic resides.
PHP » JSON » front‑end JavaScript	snake_case	Screw the front-end anyway
PHP » JSON » you do not know	snake_case	Screw the parser anyway
Java » JSON » Python	camelCase or snake_case	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Java » JSON » PHP	camelCase or snake_case	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Java » JSON » Java	camelCase	Unanimous
Java » JSON » JavaScript	camelCase	Unanimous
Java » JSON » you do not know	camelCase	Screw the parser anyway
back‑end JavaScript » JSON » Python	camelCase or snake_case	Lean on where the business logic resides.
front‑end JavaScript » JSON » Python	snake_case	Screw the front-end anyway
back‑end JavaScript » JSON » PHP	camelCase or snake_case	Lean on where the business logic resides.
front‑end JavaScript » JSON » PHP	snake_case	Screw the front-end anyway
JavaScript » JSON » Java	camelCase	Unanimous
JavaScript » JSON » JavaScript	camelCase	Original
JavaScript » JSON » you do not know	camelCase	Screw the parser anyway

驱动因素

强加命名约定非常令人困惑，因为 JSON 本身并没有强加标准。但是，如果将其分解为组件，则可以很容易地弄清楚这一点。

JSON 生成器

Programming language	Naming convention
Python	snake_case
PHP	snake_case
Java	camelCase
JavaScript	camelCase

JSON 解析器

Programming language	Naming convention
Python	snake_case
PHP	snake_case
Java	camelCase
JavaScript	camelCase

大量业务逻辑

您必须决定哪一方的业务逻辑更重，是 JSON 生成器 一方还是 JSON 解析器 一方？

自然归属

Programming language	Natural belongingness
Python	intrinsic
PHP	intrinsic
Java	extrinsic
JavaScript	intrinsic

内在 - 访问 JSON 的编程语言自然类似于访问原生对象和数组。

外部 - 访问 JSON 的编程语言不同于访问本机对象和数组。下面是 Java 的 com.google.gson 包的示例：

/**
 * Using a method to access a property instead of using the standard 'dot.syntax'
 */
JsonElement.getAsString("snake_cased_key");

一些实际的实现

Google Maps JavaScript API - 驼峰式 Facebook JavaScript API - snake_cased Amazon Web Services - snake_cased & camelCased Twitter API - snake_cased JSON-LD - 驼峰式

结论

为您的 JSON 实现选择正确的 JSON 命名约定取决于您的技术堆栈。在某些情况下，您可以使用 snake_case、camelCase 或任何其他命名约定。

要考虑的另一件事是 JSON 生成器与 JSON 解析器和/或前端 JavaScript 的权重。一般来说，业务逻辑方面应该更加重视。

此外，如果 JSON 解析器方面未知，那么您可以声明什么可以为您工作。

【讨论】：

"Person":isn't camelCase :)

@stoft 这可能是因为他们也遵循 schema.org 的约定。以大写字母开头的键意味着它是一个词汇实体。以小写字母开头的键意味着这是一个词汇属性。

我不同意这些想法，仅仅因为 Python 后端 > Java 前端应该是驼峰式，但是你添加了 Python 前端，你已经妥协了后端和一个前端。它应该是后端的“标准”。无论如何，前端解析器都更容易适应

我担心这里提到了“你的技术”堆栈。 JSON 的生产者，尤其是如果由 HTTP 服务器提供服务时，应该不知道谁或什么在使用它，或者出于什么原因。如果 JSON 被用作许多生产者和消费者之间的一种通信方式，那么生产者的技术堆栈应该不是考虑因素。

@RobbieWareham 我同意这一点。这里的事情是“按照标准”，没有正式的命名约定。因此，也许人们应该选择“事实上”，即查看技术堆栈。我认为研究技术堆栈是最好的方法。看看 facebook，他们在历史上是否尊重 JavaScript 并使用snakeCase？不！他们选择坚持使用 PHP 的 snake_case。

【参考方案4】：

对我来说尤其是在 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 命名约定之间的快乐媒介。

【讨论】：

这里也一样。在 android 客户端接收带有 snake_case 的 JSON 看起来很尴尬！！此外，数据库不区分列名的大小写，因此 snake_case 似乎最适合数据库。

@mythicalcoder Java 中的 JSON 在其核心中并不是固有的。 Java 仅使用外部包来解析 Java，例如org.json，gson。接收snake_case 数据并没有那么大的伤害……JSONObject.get('snake_case_key_here')

【参考方案5】：

似乎有足够的变化，人们不遗余力地允许从所有约定转换为其他约定：http://www.cowtowncoder.com/blog/archives/cat_json.html

值得注意的是，上面提到的 Jackson JSON 解析器更喜欢 bean_naming。

【讨论】：

小更正：Jackson 默认使用 Java bean 命名约定，即（小）驼峰式，如 beanNaming。

【参考方案6】：

我认为 JSON 没有正式的命名约定，但您可以关注一些行业领导者，看看它是如何工作的。

Google 是世界上最大的 IT 公司之一，它有一个 JSON 样式指南：https://google.github.io/styleguide/jsoncstyleguide.xml

利用这一优势，您可以在此处找到 Google 定义的其他样式指南：https://github.com/google/styleguide

【参考方案7】：

正如其他人所说，没有标准，所以你应该自己选择一个。这样做时需要考虑以下几点：

如果您使用 JavaScript 来使用 JSON，那么对两者中的属性使用相同的命名约定将提供视觉一致性，并可能为更清晰的代码重用提供一些机会。

避免 kebab-case 的一个小原因是连字符可能会与值中出现的 - 字符在视觉上发生冲突。

  "bank-balance": -10

【讨论】：

snake_case 使用下划线，而不是破折号。