

Google JavaScript style guidelines - andreyf
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

======
WilliamLP
With JavaScript, there is an interesting contrast between what its fans say
are its strengths and what battle-hardened experience actually requires you to
do.

For example:

\- Prototype object systems are great... except don't actually use this, it
doesn't really work. Use our simulation of a classical object system instead.

\- Lambdas are wonderful and powerful when combined with closures... except
they leak memory. Don't use them, but declare named functions.

\- The 'this' parameter was a stupid idea. Use it as little as possible,
except when absolutely necessary.

\- Be really conscious all the time, because of a stupid and misguided semi-
colon insertion feature that will mess you up.

\- Don't bother trying to use anything other than C style for loops over
collections. They mess you up.

\- The dynamic type system is nice... however experience shows us that what we
really want is actually a static system, so JavaDoc types of everything with a
cumbersome and extremely verbose syntax instead.

\- Extending prototypes of existing objects is an amazing and powerful
feature. Please don't ever use it.

~~~
halo
You've set up a straw man argument. Where are these JavaScript fans who are
pointing to several well-known problems with the language (e.g. semicolon
autoinsertion, the for-in loop, the poorly-thought-out type system) and saying
they're JavaScript's strengths? No-one is saying the language doesn't have
flaws.

JavaScript's strengths are that it's small and surprisingly powerful and
flexible, in spite of its design mistakes.

(N.B. The bug with closures is associated with a problem in a single use case
with IE6's garbage collector, and Microsoft patched it two-and-a-half years
ago.)

~~~
statictype
_N.B. The bug with closures is associated with a problem in a single use case
with IE6's garbage collector, and Microsoft patched it two-and-a-half years
ago._

Are you sure about that? From what I understood they couldn't patch it because
some major unnamed web sites actually _relied_ on DOM elements not being
cleaned up to work properly.

[http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53028...](http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53028.aspx)

As of IE 7, I remember I still had to close out memory leaks on some code that
was binding an event to a DOM node.

~~~
pornel
That blog post shows their workaround for faulty GC caused problems, not that
correct GC wouldn't work.

My guess is that forced DOM tear-down broke cross-frame/window references.
This is not necessary in implementations that let GC clean up DOM nodes.

------
theycallmemorty
> Relying on implicit insertion can cause subtle, hard to debug problems.
> Don't do it. You're better than that.

I loved that quote.

------
jasonkester
Nice. I'd never before seen a company language style guide where I agreed with
every single point (Though I do tend to use "this" within my own classes, so I
guess we're not in _complete_ agreement).

Great, concise explanations of why each point is good or bad (or not an
issue). Opting for readability and debugability every time there's a choice.

Favorite quote: "You're better than that."

------
Amnon
The "tips and tricks" section is interesting. I didn't know that iterating
over node lists can take O(n^2). Also the Closure Compiler was new to me.

------
andreyf
I wonder what an IDE that enforces all of these guidelines would be like?

~~~
goodside
If guidelines were meant to be enforced, they'd be syntax.

~~~
pgbovine
not necessarily ... official language standards bodies might make decisions
much more slowly than individual hackers or groups, and even when a feature is
officially baked into a new version of the syntax, it might take
compilers/interpreters several more years to all implement them properly.
there's definitely a need for good lightweight static checking of guidelines
in IDEs

------
exit
why does javascript have a const keyword which shouldn't be used?

~~~
markkanof
The document says not to use const but you can use @const when appropriate.
Can anyone explain what @const does? In the documentation example code it
looks like it is just in the comments.

~~~
riprock
My other comment touches on this but the Closure Compiler parses the JSDoc
comments and gives warnings for rules that are violated in the code.

