3 ms·

I totally agree, however it's get a bit tricky on the boundaries between an underscore and camelCased language. For example sending json between the client and

I totally agree, however it's get a bit tricky on the boundaries between an underscore and camelCased language. For example sending json between the client and server. Should the json keys be camelCased or underscore_cased? It's a bit ambigious.

mcav 17y ago
Yes. I run a Python server, so there's conflict between "long_name" and "longName", and even "long-name" (which I think is semantically superior). I'm curious to hear how other people have approached encoding multi-word values in JSON and XML.
- jashkenas 17y ago
  Right, and then HTML/CSS ids and classes further muddy the waters. It's usually worth keeping at least your model attributes with the same name, from DB column through Web App to JS. So we do: doc.set({related_article : 'http://...'}); Even though you might have: doc.openRelatedArticle(); As a method on the JS model. Definitely less than ideal.
- IgorPartola 17y ago
  For me, data passed from server to client is encoded as long_name. The reason here being that I name database columns long_name and thus propagating this structure all the way down makes sense. Most other things are camelCased, except local_variables.
- sh1mmer 17y ago
  Why not write a function that does it automagically and then forget about it?
- ableal 17y ago
  > "long-name" (which I think is semantically superior) except if you're trying to subtract: c = a-b which is why languages with arithmetic don't allow '-' in variable names. (Then function/method names get the same rule. KISS.)
tpz 17y ago
Ambiguous? JavaScript Object Notation should probably use JavaScript's camelCasing, no? ;)
- binspace 17y ago
  I agree with your point. But often times it is used exclusively (or in majority) on the server-side. If the server side language follows the underscore_case convention. That's where the ambiguity creeps in.
mpk 17y ago
I've written a (non-OSS, so no link, sorry) lib in JS that I ported to Ruby, C# and Java. The API methods in JavaScript are all lower camelCase as are the Java ones. The C# ones are all upper CamelCase and the Ruby ones are all lower snake_case (or whatever it's called). Basically, I try to follow the conventions of whatever language I'm working in because that just makes it easier for people working in that language to incorporate your lib. And yes, lowerCamel seems to be the default for JS. For a JSON wire protocol it's different, because it's not a language specific API that you're exposing, it's a protocol, which is a different beast. For text-based wire-protocols I prefer to 'ignore' case (because of ambiguity) by sticking with lowercase all the way. Names need separators and the underscore works nicely for that everywhere. Keys I use for sending over the wire therefore follow the Ruby style.
derefr 17y ago
In correct JSON, all strings have to be quoted, even keys. Why not just use, instead of o["fooBar"] or o["foo_bar"], o["foo bar"] You know, actual spaces? Spaces don't make for valid variable/method identifiers in most languages, yes, but it's not like keys you received from the network should be leaking into your identifier namespace anyway—that's how MITM attacks start.

mcav 17y ago

Yes. I run a Python server, so there's conflict between "long_name" and "longName", and even "long-name" (which I think is semantically superior). I'm curious to hear how other people have approached encoding multi-word values in JSON and XML.

jashkenas 17y ago
Right, and then HTML/CSS ids and classes further muddy the waters. It's usually worth keeping at least your model attributes with the same name, from DB column through Web App to JS. So we do: doc.set({related_article : 'http://...'}); Even though you might have: doc.openRelatedArticle(); As a method on the JS model. Definitely less than ideal.
IgorPartola 17y ago
For me, data passed from server to client is encoded as long_name. The reason here being that I name database columns long_name and thus propagating this structure all the way down makes sense. Most other things are camelCased, except local_variables.
sh1mmer 17y ago
Why not write a function that does it automagically and then forget about it?
ableal 17y ago
> "long-name" (which I think is semantically superior) except if you're trying to subtract: c = a-b which is why languages with arithmetic don't allow '-' in variable names. (Then function/method names get the same rule. KISS.)

tpz 17y ago

Ambiguous? JavaScript Object Notation should probably use JavaScript's camelCasing, no? ;)

binspace 17y ago
I agree with your point. But often times it is used exclusively (or in majority) on the server-side. If the server side language follows the underscore_case convention. That's where the ambiguity creeps in.

mpk 17y ago

I've written a (non-OSS, so no link, sorry) lib in JS that I ported to Ruby, C# and Java. The API methods in JavaScript are all lower camelCase as are the Java ones. The C# ones are all upper CamelCase and the Ruby ones are all lower snake_case (or whatever it's called). Basically, I try to follow the conventions of whatever language I'm working in because that just makes it easier for people working in that language to incorporate your lib. And yes, lowerCamel seems to be the default for JS. For a JSON wire protocol it's different, because it's not a language specific API that you're exposing, it's a protocol, which is a different beast. For text-based wire-protocols I prefer to 'ignore' case (because of ambiguity) by sticking with lowercase all the way. Names need separators and the underscore works nicely for that everywhere. Keys I use for sending over the wire therefore follow the Ruby style.

derefr 17y ago

In correct JSON, all strings have to be quoted, even keys. Why not just use, instead of o["fooBar"] or o["foo_bar"], o["foo bar"] You know, actual spaces? Spaces don't make for valid variable/method identifiers in most languages, yes, but it's not like keys you received from the network should be leaking into your identifier namespace anyway—that's how MITM attacks start.