JSON: Inconsistency with JavaScript naming standards

[Krxtopher]

Why do we recommend camelCase ("myProperty") for our JavaScript standards but underscores ("my_property_name")? I'd rather we be consistent (and I vote camelCase). If not, it could lead to some odd looking JavaScript code for objects that may contain properties populated by JSON objects. For example…

var title = searchService.previousResult.book_title;

[lkrids]

+1

[nicetransition]

I see what you mean, there was a definite reason for using underscore but I can't remember why or where we got that as a source.

@LukeAskew or @mcgaryes - do you have feedback?

[LukeAskew]

@tobius Also brought this to my attention.

Let's talk about it.

I wrote this draft with APIs in mind. A lot of APIs I've worked with use underscores in property names and I like that convention.

Using a different convention from JSON to JavaScript could help distinguish properties that originate from an API from normal JS objects.

[nicetransition]

Ah that was the concept I remember "Using a different convention from JSON to JavaScript could help distinguish properties that originate from an API from normal JS objects."

[Krxtopher]

You might be able to sell me on the "other APIs do it", but I think the argument about being able to tell what properties come from JSON is actually an argument against it. The implementations details behind an object should be hidden. You should not be able to tell whether a property is backed by a JSON object because that is an implementation detail that should be allowed to be changed easily in the future. Maybe today property "z" is backed by an object that come from a JSON service, but tomorrow it may need to come from an XML feed or a binary socket server. To put it another way, the name of a property or method should not expose how it is implemented.