JSON命名约定

Geo*_*geU 341 json json.net

JSON命名是否有标准?我看到大多数使用由下划线(lower_case)分隔的小写的示例.但是,你可以使用PascalCase或camelCase吗?

Tho*_*Tho 362

在本文档中,Google JSON样式指南(在Google上构建JSON API的建议),

它建议:

  1. 属性名称必须是camelCased,ASCII字符串.

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

例:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}
Run Code Online (Sandbox Code Playgroud)

我们的团队使用此惯例.

  • @TheEye它仍在那里,你只需要点击下拉菜单. (31认同)
  • 显然谷歌已经改变了指导方针,没有找到关于骆驼案件或者在文件中以字母,_或$开头的事情...... (7认同)
  • 好眼,@ gdw2.对于将来的其他人,如果您通过"属性名称指南 - >属性名称格式 - >选择有意义的属性名称"单击箭头按钮. (5认同)
  • 有人可以解释为什么以及何时使用下划线为属性名称添加前缀?参考将是有用的,而不仅仅是一种意见. (3认同)
  • 这里也是一个热门话题https://github.com/json-api/json-api/pull/1247 (3认同)
  • 这并不能回答问题。这只是众多风格指南之一,还有许多其他风格指南要求使用 Snake_Case、PascalCase 和 CamelCase。引用你自己团队的偏好是无关紧要的。下面阿贝尔的回答是对这个问题的更好的回答。 (3认同)
  • @MaduraPradeep ProperCase也是驼峰式的,有时也称为UpperCamelCase.https://en.wikipedia.org/wiki/Camel_case (2认同)
  • 引用Google并不是一个恰当的答案。它们仅支持特定的约定/准则,并且看起来很像Java,因为它们非常面向Java。 (2认同)

Sta*_*Man 224

没有SINGLE标准,但我看到你提到的3种风格("Pascal/Microsoft","Java"(camelCase)和"C"(下划线snake_case)) - 以及至少还有一种(kebab-caselonger-name).

它似乎主要取决于有问题的服务的开发者的背景; 具有c/c ++背景的那些(或采用类似命名的语言,包括许多脚本语言,ruby等)通常选择下划线变体; 类似地(Java vs .NET).例如,提到的杰克逊库假设Java bean命名约定(camelCase)

更新:我对"标准"的定义是一个单一的约定.因此,虽然人们可以声称"是的,有许多标准",但对我来说有多个Naming Conventions,其中没有一个是"标准".其中一个可以被认为是特定平台的标准,但是考虑到JSON用于平台之间的互操作性,这可能或者可能没有多大意义.

  • 看到一些统计数据会很有意思,因为声称JSON和Javascript之间存在联系的人(不仅仅是历史遗产)之间存在持续的摩擦,而那些认为目前很少将JSON连接到Javascript的人之间存在摩擦.我属于后一阵营.但我有兴趣了解相对使用模式. (5认同)
  • 坚持开发人员的背景很重要,但JSON坚持使用Javascript标准.你的第一个陈述不太正确.但绝对坚持你的团队的命名惯例. (4认同)
  • @StaxMan C# 在大多数情况下使用 PascalCase,而不是 camelCase。 (3认同)

Abe*_*ejo 157

前提

在JSON键没有标准的命名.

驱动因素

强加JSON命名约定非常令人困惑.但是,如果将其分解为组件,可以很容易地理解这一点.

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

    • Python - snake_case
    • PHP - snake_case
    • Java - camelCase
    • JavaScript - camelCase
  2. JSON本身没有标准的密钥命名

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

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

混合匹配组件

  1. Python »JSON» Python - snake_case
  2. Python »JSON» PHP - snake_case
  3. Python »JSON» Java - snake_casecamelCase
  4. Python »JSON» JavaScript - snake_case会有意义; 无论如何拧紧前端
  5. Python »JSON»你不知道 - snake_case会有意义; 无论如何拧紧解析器
  6. PHP »JSON» Python - snake_case
  7. PHP »JSON» PHP - snake_case
  8. PHP »JSON» Java - snake_casecamelCase
  9. PHP »JSON» JavaScript - snake_case会有意义; 无论如何拧紧前端
  10. PHP »JSON» PHP - snake_case
  11. PHP »JSON»你不知道 - snake_case会有意义; 无论如何拧紧解析器
  12. Java »JSON» Python - camelCasesnake_case
  13. Java »JSON» PHP - camelCasesnake_case
  14. Java »JSON» Java - camelCase
  15. Java »JSON» JavaScript - camelCase
  16. Java »JSON»你不知道 - camelCase会有意义; 无论如何拧紧解析器
  17. JavaScript »JSON» Python - snake_case会有意义; 无论如何拧紧前端
  18. JavaScript »JSON» PHP - snake_case会有意义; 无论如何拧紧前端
  19. JavaScript »JSON» Java - camelCase
  20. JavaScript »JSON» JavaScript - camelCase

一些实际的实现

结论

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

另一件需要考虑的事情是JSON生成器与JSON解析器和/或前端JavaScript的权重.通常,应该在JSON生成器端而不是JSON-parser端放置更多权重.这是因为业务逻辑通常驻留在JSON生成器端.

此外,如果JSON-parser端未知,那么您可以声明什么可以为您工作.

  • 我担心的是这里提到了“你的技术”堆栈。JSON 的生产者,尤其是如果要由 HTTP 服务器提供服务时,不应该知道谁或什么正在使用它,或者出于什么原因。如果将 JSON 用作许多生产者和消费者之间的通信方式,那么生产者的技术堆栈不应成为考虑因素。 (6认同)
  • @RobbieWareham 我在某种程度上同意这一点。这里的问题是,“按照标准”,没有正式的命名约定。因此,也许人们应该选择“事实上”,即查看技术堆栈。我认为研究技术堆栈是最好的方法。看看 facebook,他们历史上是否尊重 JavaScript 并使用 SnakeCase?不!他们选择坚持使用 PHP 的 Snake_case。 (3认同)
  • `“ Person”:`不是骆驼案例:) (2认同)
  • 我不同意这些想法,只是因为Python后端> Java前端应该是camelCase,但是你添加了Python前端,你已经破坏了后端和一个前端.它应该是后端如何通过"标准".前端解析器无论如何都更容易适应 (2认同)
  • 虽然我有些同意你的回答。我对“有意义”和“螺丝前端”的选择理由感到不舒服。后端命名约定在 JSON 命名风格中更重要的一个重要原因是,它自然倾向于创建而不是读取这些结构,并且匹配的命名风格也减少了很多愚蠢的映射代码,使事情在微妙的部分变得更简单。应用程序。前端框架和库在这方面更加灵活,错误“只会”导致 UI 错误。 (2认同)

Cla*_*Liu 16

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

这是因为数据库字段有很多缩略词/缩写所以像appSNSInterfaceRRTest看起来有点混乱,但app_sns_interface_rr_test更佳.

在Javascript变量中,所有camelCase和类名(构造函数)都是ProperCase,所以你会看到像

var devTask = {
        task_id: 120,
        store_id: 2118,
        task_name: 'generalLedger'
    };
Run Code Online (Sandbox Code Playgroud)

要么

generalLedgerTask = new GeneralLedgerTask( devTask );
Run Code Online (Sandbox Code Playgroud)

当然,在JSON键/字符串中用双引号括起来,但是你只需使用JSON.stringify并传入JS对象,所以不必担心.

我一直在努力解决这个问题,直到我在JSON和JS命名约定之间找到了这个愉快的媒介.


ent*_*opo 9

似乎有足够的变化,人们会竭尽全力允许从所有约定转换到其他约定:http://www.cowtowncoder.com/blog/archives/cat_json.html

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

  • 小修正:Jackson默认使用Java bean命名约定,这是(较低的)Camel Case,如`beanNaming`. (3认同)