Take the 2-minute tour ×

What are some things I must verify before taking an existing code base and converting it to Strict Mode?

The project is a website that is designed to run on all browsers from IE 8 and above, and doesn't have a lot of unit tests or a js linter continuous integration setup at this point.

  1. What are some language features to look out for, that our own code, or libraries that we use might be using, that will silently break if I turn on strict mode?
  2. Is there a code analysis process that can look at my whole project, and point out the specific pitfalls from this migration?
  3. Any particular browsers I should be worried about? (Well, I guess IE 8 is the usual suspect ... but what exactly to look for in IE's 8 support, or lackthereof, of strict mode?)
  4. If I'm not looking for raw performance, but first at avoiding bugs ... is strict mode a cost effective way to help early bug detection?
share|improve this question
You can use Kangax' Strict mode table to check which particular strict mode-features are available in the browser you're testing. Saves some headaches with determining the differences in strict mode implementations. –  Rob W Feb 25 '12 at 14:20
add comment

2 Answers

The one bit of strict code that I violate most is the strict delete operator.

delete someobject.someproperty throws an error if someobject.someproperty is not defined, while in 'normal' code it deletes the property if it exists, and carries on without an error if it doesn't.

It's easy to fix-

if('someproperty' in someobject) delete someobject.someproperty;

I liked the old way, but things change. Some people hate giving up arguments.callee...

share|improve this answer
add comment

You can avoid prototype chaining by changing the code as follows:

if (someObject.hasOwnProperty("someProperty")) {
    delete someObject.someProperty;
share|improve this answer
add comment

Your Answer


