styleguide practices practice google best json json.net

google - json structure best practices



Convención de nombres JSON (7)

¿Hay algún estándar en la denominación JSON? Veo que la mayoría de los ejemplos usan minúsculas separadas por guiones bajos (lower_case). Pero, ¿puedes usar PascalCase o camelCase?

Premisa

No hay un nombre estándar de claves en JSON .

Factores de conducción

Imponer una convención de nombres JSON es muy confuso. Sin embargo, esto se puede resolver fácilmente si se divide en componentes.

  1. Lenguaje de programación para generar JSON.

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

  2. JSON en sí no tiene un nombre estándar de teclas

  3. Lenguaje de programación para analizar JSON

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

Mezclar-emparejar los componentes

  1. Python »JSON» Python - snake_case
  2. Python »JSON» PHP - snake_case
  3. Python »JSON» Java - snake_case o camelCase
  4. Python »JSON» JavaScript - snake_case tendrá sentido; atornille la parte delantera de todos modos
  5. Python »JSON» que no sabes - snake_case tendrá sentido; atornille el analizador de todos modos
  6. PHP »JSON» Python - snake_case
  7. PHP »JSON» PHP - snake_case
  8. PHP »JSON» Java - snake_case o camelCase
  9. PHP »JSON» JavaScript - snake_case tendrá sentido; atornille la parte delantera de todos modos
  10. PHP »JSON» PHP - snake_case
  11. PHP »JSON» que no sabes - snake_case tendrá sentido; atornille el analizador de todos modos
  12. Java »JSON» Python - camelCase o snake_case
  13. Java »JSON» PHP - camelCase o snake_case
  14. Java »JSON» Java - camelCase
  15. Java »JSON» JavaScript - camelCase
  16. Java »JSON» que no sabes - camelCase tendrá sentido; atornille el analizador de todos modos
  17. JavaScript »JSON» Python - snake_case tendrá sentido; atornille la parte delantera de todos modos
  18. JavaScript »JSON» PHP - snake_case tendrá sentido; atornille la parte delantera de todos modos
  19. JavaScript »JSON» Java - camelCase
  20. JavaScript »JSON» JavaScript - camelCase

Algunas implementaciones reales

Conclusiones

La elección de la convención de nombres JSON correcta para su implementación JSON depende de su pila de tecnología. Hay casos en los que se puede usar snake_case , camelCase o cualquier otra convención de nombres.

Otra cosa a considerar es el peso que se debe poner en el generador JSON frente al analizador JSON. En general, se debe poner más peso en el lado del generador JSON en lugar del lado del analizador JSON. Esto se debe a que la lógica de negocios generalmente reside en el lado del generador JSON.

Además, si desconoce el lado del analizador JSON, puede declarar lo que puede funcionar para usted.

Como han dicho otros, no hay un estándar, así que debes elegir uno por ti mismo. Aquí hay un par de cosas a considerar al hacerlo:

  1. Si está utilizando JavaScript para consumir JSON, el uso de la misma convención de nomenclatura para las propiedades proporcionará una consistencia visual y posiblemente algunas oportunidades para la reutilización de códigos más limpios.

  2. Una pequeña razón para evitar el caso de kebab es que los guiones pueden chocar visualmente con los caracteres que aparecen en los valores.

    { "bank-balance": -10 }

En este documento Google JSON Style Guide (recomendaciones para crear API de JSON en Google),

Recomienda que:

  1. Los nombres de las propiedades deben ser camelCased , cadenas ASCII.

  2. El primer carácter debe ser una letra, un guión bajo (_) o un signo de dólar ($).

Ejemplo:

{ "thisPropertyIsAnIdentifier": "identifier value" }

Nuestro equipo utiliza esta convención.

En particular para mí en NodeJS, si estoy trabajando con bases de datos y mis nombres de campo están separados por un guión bajo, también los uso en las claves de estructura.

Esto se debe a que los campos de la base de datos tienen muchos acrónimos / abreviaturas, por lo que algo como appSNSInterfaceRRTest parece un poco desordenado pero app_sns_interface_rr_test es más agradable.

En Javascript las variables son todas camelCase y los nombres de clase (constructores) son ProperCase, por lo que verías algo como

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

o

generalLedgerTask = new GeneralLedgerTask( devTask );

Y, por supuesto, en JSON, las claves / cadenas están entre comillas dobles, pero luego solo usa JSON.stringify y pasa los objetos JS, así que no debe preocuparse por eso.

Luché con esto un poco hasta que encontré este medio feliz entre las convenciones de nombres de JSON y JS.

Parece que hay suficiente variación para que las personas hagan todo lo posible para permitir la conversión de todas las convenciones a otras: http://www.cowtowncoder.com/blog/archives/cat_json.html

En particular, el mencionado analizador Jackson JSON prefiere bean_naming .

No hay UN SOLO estándar, pero he visto 3 estilos que mencionas ("Pascal / Microsoft", "Java" ( camelCase ) y "C" (guiones bajos, snake_case )), así como al menos uno más, kebab-case como longer-name ).

En su mayoría, parece depender de los antecedentes que tenían los desarrolladores del servicio en cuestión; las personas con antecedentes en c / c ++ (o idiomas que adoptan nombres similares, que incluyen muchos lenguajes de scripting, ruby, etc.) a menudo eligen la variante de subrayado; y descansar de manera similar (Java vs .NET). La biblioteca de Jackson que se mencionó, por ejemplo, asume la convención de nomenclatura de camelCase Java ( camelCase )

ACTUALIZACIÓN: mi definición de "estándar" es una convención ÚNICA. Entonces, si bien uno podría decir "sí, hay muchos estándares", para mí hay varios Naming Conventions , ninguno de los cuales es "El" estándar general. Uno de ellos podría considerarse el estándar para una plataforma específica, pero dado que JSON se utiliza para la interoperabilidad entre plataformas que puede o no tener mucho sentido.