JSON 命名约定

JSON Naming Convention

提问by GeorgeU

Is there a standard on JSON naming? I see most examples using all lower case separated by underscore (lower_case). But, can you use PascalCase or camelCase?

JSON 命名有标准吗？我看到大多数示例都使用由下划线（lower_case）分隔的所有小写字母。但是，您可以使用 PascalCase 或 camelCase 吗？

采纳答案by StaxMan

There is no SINGLE standard, but I have seen 3 styles you mention ("Pascal/Microsoft", "Java" (camelCase) and "C" (underscores, snake_case)) -- as well as at least one more, kebab-caselike longer-name).

没有 SINGLE 标准，但我已经看到了您提到的 3 种样式（“Pascal/Microsoft”、“Java”（camelCase）和“C”（下划线、snake_case））——以及至少一种，kebab-case例如longer-name）。

It mostly seems to depend on what background developers of the service in question had; those with c/c++ background (or languages that adopt similar naming, which includes many scripting languages, ruby etc) often choose underscore variant; and rest similarly (Java vs .NET). Hymanson library that was mentioned, for example, assumes Java bean naming convention (camelCase)

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

UPDATE: my definition of "standard" is a SINGLE convention. So while one could claim "yes, there are many standards", to me there are multiple Naming Conventions, none of which is "The" standard overall. One of them could be considered the standard for specific platform, but given that JSON is used for interoperability between platforms that may or may not make much sense.

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

回答by Tho

In this document Google JSON Style Guide(recommendations for building JSON APIs at Google),

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

It recommends that:

它建议：

1. Property names must be camelCased, ASCII strings.

2. The first character must be a letter, an underscore (_) or a dollar sign ($).

1. 属性名称必须是驼峰式、ASCII 字符串。

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

Example:

例子：

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

My team follows this convention.

我的团队遵循这个约定。

回答by Abel Callejo

Premise

前提

There is no standard naming of keys in JSON. According to the Objectssection of the spec:

有在JSON键没有标准的命名。根据规范的对象部分：

The JSON syntax does not impose any restrictions on the strings used as names,...

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

Which means camelCaseor snake_caseshould work fine.

这意味着camelCase或snake_case应该可以正常工作。

Driving factors

驱动因素

Imposing a JSON naming convention is very confusing. However, this can easily be figured out if you break it down into components.

强加 JSON 命名约定非常令人困惑。但是，如果您将其分解为多个组件，则很容易弄清楚这一点。

1. Programming language for generating JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

2. JSON itself has no standard naming of keys

3. Programming language for parsing JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

1. 用于生成 JSON 的编程语言

   • Python-snake_case
   • PHP-snake_case
   • Java - 驼峰式大小写
   • JavaScript - 驼峰式大小写

2. JSON 本身没有标准的键命名

3. 用于解析 JSON 的编程语言

   • Python-snake_case
   • PHP-snake_case
   • Java - 驼峰式大小写
   • JavaScript - 驼峰式大小写

Mix-match the components

混合匹配组件

1. Python? JSON ? Python- snake_case- unanimous
2. Python? JSON ? PHP- snake_case- unanimous
3. Python? JSON ? Java- snake_case- please see the Java problembelow
4. Python? JSON ? JavaScript- snake_casewill make sense; screw the front-end anyways
5. Python? JSON ? you do not know - snake_casewill make sense; screw the parser anyways
6. PHP? JSON ? Python- snake_case- unanimous
7. PHP? JSON ? PHP- snake_case- unanimous
8. PHP? JSON ? Java- snake_case- please see the Java problembelow
9. PHP? JSON ? JavaScript- snake_casewill make sense; screw the front-end anyways
10. PHP? JSON ? you do not know - snake_casewill make sense; screw the parser anyways
11. Java? JSON ? Python- snake_case- please see the Java problembelow
12. Java? JSON ? PHP- snake_case- please see the Java problembelow
13. Java? JSON ? Java- camelCase- unanimous
14. Java? JSON ? JavaScript- camelCase- unanimous
15. Java? JSON ? you do not know - camelCasewill make sense; screw the parser anyways
16. JavaScript? JSON ? Python- snake_casewill make sense; screw the front-end anyways
17. JavaScript? JSON ? PHP- snake_casewill make sense; screw the front-end anyways
18. JavaScript? JSON ? Java- camelCase- unanimous
19. JavaScript? JSON ? JavaScript- camelCase- Original

1. 蟒蛇？JSON ? Python- snake_case-一致
2. 蟒蛇？JSON ? PHP- snake_case-一致
3. 蟒蛇？JSON ? Java- snake_case- 请参阅下面的Java 问题
4. 蟒蛇？JSON ? JavaScript- snake_case会有意义；无论如何都要拧紧前端
5. 蟒蛇？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. 爪哇？JSON ? Python- snake_case-请看下面的Java问题
12. 爪哇？JSON ? PHP- snake_case- 请参阅下面的Java 问题
13. 爪哇？JSON ? Java- camelCase-一致
14. 爪哇？JSON ? JavaScript- camelCase- 一致
15. 爪哇？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 problem

Java问题

snake_casewill still make sense for those with Java entries because the existing JSON libraries for Java are using only methods to access the keys instead of using the standard dot.syntax. This means that it wouldn't hurt that much for Java to access the snake_casedkeys in comparison to the other programming language which can do the dot.syntax.

对于那些有 Java 条目的人来说，snake_case仍然有意义，因为现有的 Java JSON 库只使用方法来访问密钥，而不是使用标准的dot.syntax。这意味着与其他可以执行dot.syntax 的编程语言相比，Java 访问蛇形大小写的键不会有太大的伤害。

Example for Java'sorg.jsonpackage

Java包的例子org.json

JsonObject.getString("snake_cased_key")

JsonObject.getString("snake_cased_key")

Example for Java'scom.google.gsonpackage

Java包的例子com.google.gson

JsonElement.getAsString("snake_cased_key")

JsonElement.getAsString("snake_cased_key")

Some actual implementations

一些实际的实现

• Google Maps JavaScript API- camelCased
• Facebook JavaScript API- snake_cased
• Amazon Web Services- snake_cased& camelCased
• Twitter API- snake_cased
• JSON-LD- camelCased& ProperCamelCased

• Google Maps JavaScript API- camelCased
• Facebook JavaScript API- snake_cased
• 亚马逊网络服务- snake_cased与驼峰格式
• Twitter API- snake_cased
• JSON-LD- camelCased和ProperCamelCased

Conclusions

结论

Choosing the right JSON naming convention for your JSON implementation depends on your technology stack. There are cases where one can use snake_case, camelCase, or any other naming convention.

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

Another thing to consider is the weight to be put on the JSON-generator vs the JSON-parser and/or the front-end JavaScript. In general, more weight should be put on the JSON-generator side rather than the JSON-parser side. This is because business logic usually resides on the JSON-generator side.

另一件要考虑的事情是 JSON 生成器与 JSON 解析器和/或前端 JavaScript 的权重。一般来说，应该将更多的权重放在 JSON 生成器端而不是 JSON 解析器端。这是因为业务逻辑通常驻留在 JSON 生成器端。

Also, if the JSON-parser side is unknown then you can declare what ever can work for you.

此外，如果 JSON 解析器端未知，那么您可以声明什么对您有用。

回答by Clarence Liu

Notably for me on NodeJS, if I'm working with databases and my field names are underscore separated, I also use them in the struct keys.

特别是对于我在 NodeJS 上，如果我正在使用数据库并且我的字段名称用下划线分隔，我也会在结构键中使用它们。

This is because db fields have a lot of acronyms/abbreviations so something like appSNSInterfaceRRTestlooks a bit messy but app_sns_interface_rr_testis nicer.

这是因为 db 字段有很多首字母缩写词/缩写词，所以像appSNSInterfaceRRTest这样的东西看起来有点乱，但app_sns_interface_rr_test更好。

In Javascript variables are all camelCase and class names (constructors) are ProperCase, so you'd see something like

在 Javascript 变量中都是驼峰式的，而类名（构造函数）是 ProperCase，所以你会看到类似

var devTask = {
        task_id: 120,
        store_id: 2118,
        task_name: 'generalLedger'
    };

or

或者

generalLedgerTask = new GeneralLedgerTask( devTask );

And of course in JSON keys/strings are wrapped in double quotes, but then you just use the JSON.stringify and pass in JS objects, so don't need to worry about that.

当然，在 JSON 中，键/字符串用双引号括起来，但是您只需使用 JSON.stringify 并传入 JS 对象，因此无需担心。

I struggled with this a bit until I found this happy medium between JSON and JS naming conventions.

我为此苦苦挣扎，直到我在 JSON 和 JS 命名约定之间找到了这种快乐的媒介。

回答by entropo

Seems that there's enough variation that people go out of their way to allow conversion from all conventions to others: http://www.cowtowncoder.com/blog/archives/cat_json.html

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

Notably, the mentioned Hymanson JSON parser prefers bean_naming.

值得注意的是，提到的 Hymanson JSON 解析器更喜欢bean_naming.

回答by Filipe Brito

I think that there isn't a official naming convention to JSON, but you can follow some industry leaders to see how it is working.

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

Google, which is one of the biggest IT company of the world, has a JSON style guide: https://google.github.io/styleguide/jsoncstyleguide.xml

谷歌是世界上最大的 IT 公司之一，有一个 JSON 风格指南：https: //google.github.io/styleguide/jsoncstyleguide.xml

Taking advantage, you can find other styles guide, which Google defines, here: https://github.com/google/styleguide

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

回答by Dan

As others have stated there is no standard so you should choose one yourself. Here are a couple of things to consider when doing so:

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

1. If you are using JavaScript to consume JSON then using the same naming convention for properties in both will provide visual consistency and possibly some opportunities for cleaner code re-use.

2. A small reason to avoid kebab-case is that the hyphens may clash visually with -characters that appear in values.

   {
     "bank-balance": -10
   }
   

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

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

   {
     "bank-balance": -10
   }