
JavaScript Style - twampss
http://ozmm.org/posts/javascript_style.html
======
steamer25
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?

~~~
yangyang
> 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
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.

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

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

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

~~~
Confusion
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.

------
binspace
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
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
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.

------
hackermom
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 :)

~~~
scott_s
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.

