5 ms·
JavaScript Style
- SlyShy 17y agoPosted on April 1st, but he is, in fact, serious.
- binspace 17y agoI 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 agoYes. 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 agoRight, 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 agoFor 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 agoWhy 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 agoAmbiguous? JavaScript Object Notation should probably use JavaScript's camelCasing, no? ;)
- binspace 17y agoI 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 agoI'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 agoIn 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.
- hackermom 17y agoI 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 :)
- scott_s 17y agoThat'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.
- steamer25 17y agoI 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?
- binspace 17y agoMatz 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.
- yangyang 17y ago> 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.
- jsharpe 17y agoAgreed. As has been said many times, code is much easier to write than it is to read (or debug), so make that sacrifice now.
- _delirium 17y agoI 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
- ranza 17y agoi tend to use camelCasing in most of my code (php|js). Both class names, methods and properties. I prefix private and protected with _ though
- bluesmoon 17y agocamelCase was invented by english speakers with absolutely no clue about case-less languages.
- Confusion 17y agoAs 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.
- bluesmoon 17y agoOf course, for javascript style, crockford's articles are fairly good: http://javascript.crockford.com/style1.html http://javascript.crockford.com/style1.html and http://javascript.crockford.com/style2.html http://javascript.crockford.com/style2.html