Hacker News Reader

Comment by binspace | Hacker News Reader

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.

View on HN

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.

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.

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.

Why not write a function that does it automagically and then forget about it?

> "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.)

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.

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.

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

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.

Reply on news.ycombinator.com