I tend to prefer camelCasing even in Python, etc. It seems that underscored_names may be easier to read but camelCasedNames are easier to write. The crux is that, for me, it's harder to write underscored_names than it is to read camelCasedNames.

Can anyone point out advantages of underscored_names that I may be missing?

> underscored_names may be easier to read but camelCasedNames are easier to write

Code gets read more than once. If it makes code easier to read, I'll do it, even if it takes me a tiny bit longer to write that extra character.

Agreed. As has been said many times, code is much easier to write than it is to read (or debug), so make that sacrifice now.

I find it harder to type camel-cased names, because I seem to end up mis-timing my shift and ending up with camelcAsed or camelCAsed or even cameLCased names

i tend to use camelCasing in most of my code (php|js). Both class names, methods and properties. I prefix private and protected with _ though

Matz chose underscore_casing in Ruby because non-english speakers have an easier time reading underscore_cased words.

One can also make the argument that code is read more often than written.

Of course, for javascript style, crockford's articles are fairly good: http://javascript.crockford.com/style1.html and http://javascript.crockford.com/style2.html

Posted on April 1st, but he is, in fact, serious.

camelCase was invented by english speakers with absolutely no clue about case-less languages.

As programming languages tend to resemble English, it's pretty reasonable to use typography relevant to English. Accusations of Anglocentrism are not appropriate in that arena: programming languages are Anglocentrist.

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.

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.

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

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

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.

I interpret part of this short article as if the author, with "I'm not saying you must write JavaScript a certain way. Do what makes you the most comfortable, write code that is fun to write." implies that it's ok to write JS function names etc. in any way, which is very bad advice, because, some (or most?) JS engines have case sensitivity on function calls; Math.floor() will work, but math.floor() will throw a reference error and Math.Floor() will throw an undefined function error. Really: you must write JavaScript a certain, very specific way, or it just won't work everywhere :)

That's not what that means. The author assumes that the reader understands that your code must be legal JavaScript. It's an article about coding style, not coding correctness.