Javascript Best Practices

http://www.javascripttoolbox.com/bestpractices/

by googletron • 15 years ago

92 58 15 years ago

javascripttoolbox.com

googletron3• 15 years ago

I like alot the conventions mentioned here. It would make development a lot more pleasurable.

markerdmann• 15 years ago

This is also a great reference:

http://google-styleguide.googlecode.com/svn/trunk/javascript...

ckhoo• 15 years ago

Thanks for the link. Google's Javascript style guide in conjunction with this article's best practices really helped.

funkah2• 15 years ago

Crockford's "JavaScript: The Good Parts" is the gold standard for best practices. Pretty much anyone who works in JS will recommend it. Here's a video which is a condensed version of what's in the book: http://www.youtube.com/watch?v=hQVTIJBZook

grannyg00se• 15 years ago

I think JSLint should probably get a mention when discussing best practices. It can be rather picky but most options have toggles. (I'm particularly not fond of having to put extra spaces around operators. var j=2 looks better to me than var j = 2)

googletron3• 15 years ago

yeah thats more syntax issue. alot of the time when I hate reading javascript, when it has no structure to it.

marcins• 15 years ago

There's also JSHint (http://www.jshint.com/), a fork of JSLint with a bit more configurability.

dave1010uk3• 15 years ago

It's well worth the effort writing code that conforms to JSLint or JSHint. There are a few rules which seem excessive but if you code in a team then it's so much easier knowing that all code follows a standard.

When another programmer asks me to fix bugs in some code, I get them to make it parse JSHint first. Most of the time, fixing errors to make it conform either fixes the bug or helps them understand the code enough to fix it themselves.

loftsy• 15 years ago

I've found this to be an excellent set of guidelines though not all of this works on all js implementations.

https://live.gnome.org/GnomeShell/Gjs_StyleGuide

scarmig• 15 years ago

Do people actually use the object-as-an-associative-array property access as a general practice?

I use it when it's useful, but if the name of the property should not be determined at run-time, I always do the dot notation. I've never heard of anyone taking issue with it, either.

asolove• 15 years ago

The original quote is "When accessing object properties that are determined at run-time or which contain characters not compatible with dot notation, use square bracket notation." To which should be added: object properties that are reserved words in the language.

The most common problem here is people using the dot notation for properties like "object.default" or "object.class" that are syntactically invalid.

The rest of the article is a strange mix of good advice and some cases of pretty-bad code being presented as better than very-bad code.

jnbiche• 15 years ago

I agree completely. This article mixes obvious no-no's like using var and avoiding cluttering the global namespace with headscratchers like the one you mention.

This article would more accurately be titled best practices for DOM interactions since most of the suggestions deal with DOM issues rather than pure language issues (and most of these are easily dealt with through the use of a good library like jquery).

The Google Javascript style guide someone mentioned above is much more relevant to pure language issues, and is the one style guide I reference frequently (or should reference frequently).

bdg2• 15 years ago

> Use onclick In Anchors Instead Of javascript: Pseudo-Protocol

WHAT?

No, you do NOT mix JavaScript into your HTML elements. Total disregard for separation of concerns, maintainability nightmares abound.

You put script, surprisingly, into the <script> tag.

joshuahedlund2• 15 years ago

As I understand it, the main point of that section is what to do with the onclick handler vs. what to do with the href attribute. You can follow the suggested practices regardless of whether you put your onclick code inside the element (as in the simple example) or in the script tag (as you rightly recommend).

firefoxman12• 15 years ago

Yeah, the author is basically telling you to use what is now considered a bad practice (onclick) instead of a worse practice such as... href="javascript: dostuff()"

Hexx• 15 years ago

I think this just may be an old page.

mrpollo• 15 years ago

Surprisingly best practices dont last much on the web

epochwolf• 15 years ago

What's wrong with putting a single, reusable function call in onclick?

    <a href="/posts/1244/comments/new" onclick="Comment.new(this); return false;">New Comment</a>

lazerwalker• 15 years ago

If nothing else, it goes against the author's own rule of never using eval, albeit in this case it's an implied eval rather than explicit call to the eval() function.

bdg2• 15 years ago

1. Pollutes the DOM

2. Violates separation of concerns

3. Complicates maintainability

4. Events are bound directly to elements rather than bubbling and being managed via delegation.

funkah2• 15 years ago

Yeah, I didn't see a date anywhere, but parts of this advice seem old. That doesn't matter for some things that will never change, but nobody should be writing onclick attributes in 2012.

I have found that when you're looking for JS help or references, you should use the most recent available.

joshuahedlund2• 15 years ago

There's some good stuff here, including stuff that I've learned over the years and some stuff I didn't yet know. But I don't quite understand this one:

> GOOD: document.forms["formname"].elements["inputname"]

> BAD: document.formname.inputname

Square bracket notation is awesome for mixing in variables - it saves you from using the evil eval() - and obviously BAD is worse than GOOD, but if you have no variables what about this:

> ?: document.forms.formname.inputname

If there's no functional difference it's shorter and simpler than GOOD

brunoc• 15 years ago

Perhaps it implies that you've extracted those names into some kind of constant or configuration object or view model that you're using throughout the system; if they change, you change them in one place and the square bracket version keeps working.

I personally find it more useful to deal with forms using some kind of abstraction on top so I doubt I'd use either variations in anything other than a very simple page.

kls• 15 years ago

IIRC it has to do with backwards compatibility, but I believe that the property accessors have been there for quite a while so I don't know if it is even valid for most of the browser targeted today. It may be one of those old best practices that is no longer relevant with the exception of people targeting older browsers.

keturn• 15 years ago

I had some linting tool yell at me about this recently. It said something like '''forms["formname"] better written as forms.formname'''

locci• 15 years ago

I tend to use document.forms['foo'].elements['bar'], here's why:

I use the elements collection because the behaviour of adding each input as a property to the parent form element is a mistake.

I use the bracket notation because it highlights the difference between the implementation symbols and the actual data which is being manipulated. What I mean is that I see a property specified with the dot notation on the same level as an identifier and as such its name is just to remind us humans of its purpose, whereas a property accessed using bracket notation is important both to us and to the program since it specifies a data point.

pak• 15 years ago

Neither is great practice, in my opinion. This page looks dated in its recommendations. Any sane JavaScript that works with DOM elements should use a DOM abstraction like jQuery. Leave document.forms.fooinput.parentNode.firstChild.nextSibling.godhelpme to die in the grave of DHTML and incompatible DOMs from the IE6 era.

googletron3• 15 years ago

what do people use to make sure the JavaScript they write is valid, as they write it. Not something I run on my code after the fact?

dave1010uk3• 15 years ago

I code with SublimeText 2, which validates JS files as soon as I save them using a local Node instance of jshint.com and a plugin called SublimeLint. It took a while to set up but the productivity gain is well worth it.

techiferous• 15 years ago

Nice. Quick off-topic question: assuming you have experience with TextMate, do you find SublimeText 2 to be slightly better than TextMate or significantly better?

Stratoscope• 15 years ago

I use Komodo IDE. Both their IDE version and the free Komodo Edit have near-realtime syntax checking for JavaScript, Python, Ruby, Perl, PHP, and one or two other languages. You get red squiggly underlines for syntax errors, green squigglies for warnings. It's quite nice to know that my code is at least free of syntax errors before I even save the file.

I recommend the 7.0 release candidate:

http://downloads.activestate.com/Komodo/releases/

More info:

http://www.activestate.com/komodo-ide http://www.activestate.com/komodo-edit

plf3• 15 years ago

I'm learning CoffeeScript right now, is what I write using it always valid JavaScript?

ricardobeat3• 15 years ago

The valid CoffeeScript you write is always valid JavaScript :)

tikhonj• 15 years ago

JS2-mode for Emacs[1][2] does this. It is awesome.

[1]: Original version: http://code.google.com/p/js2-mode/

[2]: Improved (IMO) fork: https://github.com/mooz/js2-mode

Additionally, you can configure JS[HL]int to use flymake[3]. The trick is to improve performance by having it talk to a running JavaScript process (e.g. a node server) instead of starting a new one each time.

[3] http://www.emacswiki.org/emacs/FlymakeJavaScript#toc3

ricardobeat3• 15 years ago

javascript-tools for TextMate. Calls JSHint on every save and quickly gives you the number of errors. Also allows a full check using JSLint or Closure linter, minifying etc.

https://github.com/subtleGradient/javascript-tools.tmbundle

s3b• 15 years ago

I use jshint as a vim plugin.

nailer• 15 years ago

For HTML 5 All you need is:

    <script>

The type isn't necessary anymore. We know it's JS.

See http://www.w3.org/TR/html5/scripting-1.html

ryanac• 15 years ago

Interesting, just checked and this is the same for the style tag (no longer requires type), never knew that they have defaults now. :)

http://www.w3.org/TR/html5/semantics.html#attr-style-type

bsimpson2• 15 years ago

Unless you're using <script> as a ghetto <template> node (e.g. handlebars) or for WebGL. But yeah, nobody cares if you write JS without @type.

djacobs• 15 years ago

s/ghetto/standard/

cdsanchez2• 15 years ago

I don't agree that using the unary plus operator is a best practice for string->number conversions. Best practices should advocate maintainability and clarity - in this case parseFloat is the better choice for obvious reasons. Just be aware that parseFloat and unary + aren't exactly equivalent: parseFloat("10x") === 10, +"10x" === NaN.

And no, JavaScript is not a "non-typed language." AFAIK JavaScript is both dynamically and weakly typed. Being in the latter category does mean that it will implicitly convert values to other types in certain scenarios.

bsimpson2• 15 years ago

Casting with Number is also acceptable.

I don't understand why he would recommend unary as a replacement for casting. It obfuscates the intent of your code, which is especially concerning since this reads like a guide for beginners.

VMG2• 15 years ago

careful

   parseFloat("08") === parseFloat("09") === 0

http://stackoverflow.com/questions/850341

cdsanchez2• 15 years ago

That only applies to parseInt because it tries to guess the radix if one isn't supplied. parseFloat assumes base 10 and doesn't accept a radix argument.

manojlds2• 15 years ago

This is way old. Hope someone doesn't start following this. Many of the points aren't even valid now.

southern• 15 years ago

Also see http://bonsaiden.github.com/JavaScript-Garden/

Javascript Best Practices

Related Stories