¿Hay alguna razón práctica para usar cadenas entre comillas para claves JSON?

Según json.org de Crockford , un objeto JSON se compone de miembros , que se compone de pares .

Cada par está formado por una cadena y un valor , y una cadena se define como:

Una cadena es una secuencia de cero o más caracteres Unicode, entre comillas dobles, usando escapes de barra invertida. Un carácter se representa como una sola cadena de caracteres. Una cadena se parece mucho a una cadena C o Java.

Pero en la práctica, la mayoría de los programadores ni siquiera saben que una clave JSON debe estar entre comillas dobles, porque la mayoría de los navegadores no requieren el uso de comillas dobles.

¿Tiene algún sentido molestarse en rodear su JSON entre comillas dobles?

Ejemplo válido:

{
  "keyName" : 34
}

A diferencia del inválido:

{
   keyName : 34
}

La verdadera razón por la que las claves JSON deben estar entre comillas se basa en la semántica de Identifiers of ECMAScript 3.

Las palabras reservadas no se pueden utilizar como nombres de propiedad en literales de objeto sin comillas, por ejemplo:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

Mientras que si usa comillas, los nombres de las propiedades son válidos:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

El propio Crockford lo explica en esta charla , querían mantener simple el estándar JSON, y no les gustaría tener todas esas restricciones semánticas:

....

Fue entonces cuando descubrimos el problema de los nombres sin comillas. Resulta que ECMA Script 3 tiene una política de palabras reservadas. Las palabras reservadas deben citarse en la posición clave, lo que realmente es una molestia. Cuando llegué a formular esto en un estándar, no quería tener que poner todas las palabras reservadas en el estándar, porque se vería realmente estúpido.

En ese momento, estaba tratando de convencer a la gente: sí, puedes escribir aplicaciones en JavaScript, realmente va a funcionar y es un buen lenguaje. No quería decir, entonces, al mismo tiempo: ¡y mira esta cosa realmente estúpida que hicieron! Así que decidí, en cambio, citar las claves.
De esa manera, no tenemos que decirle a nadie qué tan bueno es.

Es por eso que, hasta el día de hoy, las claves se citan en JSON.

...

El estándar ECMAScript 5th Edition corrige esto, ahora en una implementación de ES5, incluso las palabras reservadas se pueden usar sin comillas, tanto en literales de objeto como en acceso de miembros ( obj.functionOk en ES5).

Solo para que conste, este estándar está siendo implementado en estos días por los proveedores de software, puede ver qué navegadores incluyen esta función en esta tabla de compatibilidad (consulte Palabras reservadas como nombres de propiedad )

Sí, es JSON no válido y se rechazará de lo contrario en muchos casos, por ejemplo, jQuery 1.4+ tiene una verificación que hace que JSON sin comillas falle silenciosamente. ¿Por qué no cumplir?

Tomemos otro ejemplo:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

... todos estos serían válidos con citas, ¿por qué no ser coherentes y utilizarlos en todos los casos, eliminando la posibilidad de un problema?

Un ejemplo más común en el mundo de los desarrolladores web: hay miles de ejemplos de HTML no válido que se procesan en la mayoría de los navegadores ... ¿Eso hace que sea menos doloroso de depurar o mantener? En absoluto, todo lo contrario.

Además, @ Matthew hace lo mejor de todo en los comentarios a continuación, esto ya falla, las claves sin comillas arrojarán un error de sintaxis JSON.parse()en todos los navegadores principales (y cualquier otro que lo implemente correctamente), puede probarlo aquí .

YAML, que de hecho es un superconjunto de JSON, admite lo que desea hacer. Aunque es un superconjunto, te permite mantenerlo tan simple como quieras.

YAML es un soplo de aire fresco y puede que valga la pena echarle un vistazo. El mejor lugar para comenzar es aquí: http://en.wikipedia.org/wiki/YAML

Hay bibliotecas para todos los idiomas bajo el sol, incluido JS, por ejemplo, https://github.com/nodeca/js-yaml