Google JavaScript style guidelines | Hacker News Reader

Google JavaScript style guidelines

google-styleguide.googlecode.com

118 pointsandreyf29 comments

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.

Prototype systems are great. I use them all the time, even in other languages. Extending prototypes of existing objects is amazing and powerful, and can be used for some beautiful data structures.

> Extending prototypes of existing objects is amazing and powerful

What can you do with it that you can't do in class-based OO languages?

Nothing you couldn't do in assembly. Just easier and more elegant.

Could you give an example? I'm curious, because I've never found any difficulties subclassing in a class-based language.

What extra does prototype-based subclassing give me?

UI example from NewtonScript http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.... (pdf)

Found it useful, thanks.

There is nothing wrong with extending the prototypes of objects, as long as they are objects you own. Don't modify what you don't own is sound advice that applies to many things. I wish they went into detail on what the problem is with multi-level prototype hierarchies.

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

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

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.

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.

Leaky closures are not JS "feature", but a bug in one implementation (IE<8's GC doesn't clean up cycles). Other browsers handle that fine.

Similarly object enumeration is tricky business because implementations don't agree, especially IE<9 doesn't support DontEnum attribute properly.

Type systems can be debated endlessly. In this case I think Google's choice might be motivated by GWT (avoids impedance mismatch with Java).

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

I loved that quote.

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

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.

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

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

well said

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

No, because guidelines can be overridden when there's a good case for doing so. Not so with syntax.

Agreed. "Style is only necessary where understanding is lacking." - Doug Hoyte

You don't need an IDE for that, but some code analyzers do give you hints/warnings. There's something for Python (google it)

While it doesn't enforce the guidelines, their Closure Compiler enforces the variable types and encapsulations declared in the JSDoc comments with warnings. http://code.google.com/closure/compiler/

On another note, a Google engineer argues against Crockford's arguments for functional inheritance while pitching the benefits of the Closure Compiler and Library: http://www.bolinfest.com/javascript/inheritance.php I find his points are well made.

Also check out Bolin's "Closure: The definitive guide" book, available as a rough cut. A great book indeed.

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

The inclusion of const in JS predates its use by Microsoft in Internet Explorer, which doesn't support it (at least up to IE6). It's not that it won't respect its const-iness; it won't even do the initial assignment. The original designers at Netscape couldn't have foreseen this, so it's in the language.

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.

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.

many of the reserved words in js are taken from java.

abstract goto debugger enum native implements protected synchronized throws transient volatile

^^ All 'reserved' for future use.

const is used in the js 2.0 spec though.

Reply on news.ycombinator.com