JavaScript: Strict Mode Explanation – What does “use strict” all about

This article about explanation for Javascript Strict Mode. There might interest you by: John Resig – ECMAScript 5 Strict Mode, JSON, and More

To quote some interesting parts:

Strict Mode is a new feature in ECMAScript 5 that allows you to place a program, or a function, in a “strict” operating context. This strict context prevents certain actions from being taken and throws more exceptions.

And:

Strict mode helps out in a couple ways:

  • It catches some common coding bloopers, throwing exceptions.
  • It prevents, or throws errors, when relatively “unsafe” actions are taken (such as gaining access to the global object).
  • It disables features that are confusing or poorly thought out.

1. Apply in code

To apply strict mode, it’s just a string place in your JavaScript files (either at the top of your file or inside of a function) that looks like this:

Putting it in your code shouldn’t cause any problems with current browsers as it’s just a string. It may cause problems with your code in the future if your code violates the pragma. For instance, if you currently have foo = “bar” without defining foo first, your code will start failing.

Also note you can apply “strict mode” to the whole file, or use it only for a specific function (still quoting from John Resig’s article):

2. List of features (non-exhaustive)

  1. Disallows global variables. (Catches missing var declarations and typos in variable names)

  2. Silent failing assignments will throw error in strict mode (assigning NaN = 5;)

  3. Attempts to delete undeletable properties will throw (delete Object.prototype)

  4. Requires all property names in an object literal to be unique (var x = {x1: "1", x1: "2"})

  5. Function parameter names must be unique (function sum (x, x) {...})

  6. Forbids octal syntax (var x = 023;// some devs assume wrongly that a preceding zero does nothing to change the number.)

  7. Forbids the with keyword eval in strict mode does not introduce new variables

  8. Forbids deleting plain names (delete x;)

  9. Forbids binding or assignment of the names eval and arguments in any form

  10. Strict mode does not alias properties of the arguments object with the formal parameters. (i.e. in function sum (a,b) { return arguments[0] + b;} This works because arguments[0] is bound to a and so on. )

  11. arguments.callee is not supported

3. A word of caution

Applying “use strict” to existing code can be hazardous! This thing is not some feel-good, happy-face sticker that you can slap on the code to make it ‘better’. With the “use strict” pragma, the browser will suddenly THROW exceptions in random places that it never threw before just because at that spot you are doing something that default/loose JavaScript happily allows but strict JavaScript abhors! You may have strictness violations hiding in seldom used calls in your code that will only throw an exception when they do eventually get run – say, in the production environment that your paying customers use!

If you are going to take the plunge, it is a good idea to apply “use strict” alongside comprehensive unit tests and a strictly configured JSHint build task that will give you some confidence that there is no dark corner of your module that will blow up horribly just because you’ve turned on Strict Mode. Or, hey, here’s another option: just don’t add “use strict” to any of your legacy code, it’s probably safer that way, honestly. DEFINITELY DO NOT add “use strict” to any modules you do not own or maintain, like third party modules.

I think even though it is a deadly caged animal, “use strict” can be good stuff, but you have to do it right. The best time to go strict is when your project is greenfield and you are starting from scratch. Configure JSHint/JSLint with all the warnings and options cranked up as tight as your team can stomach, get a good build/test/assert system du jour rigged like Grunt+Karma+Chai, and only THEN start marking all your new modules as “use strict”. Be prepared to cure lots of niggly errors and warnings. Make sure everyone understands the gravity by configuring the build to FAIL if JSHint/JSLint produces any violations.

4. Browsers support

Currently, it’s supported by all major browsers (bar IE 9 and below). Modern JavaScript practice should always evoke the “Use Strict”; pragma. The only reason that the ECMA Group has made the “Strict” mode optional is to permit less experienced coders access to JavaScript and give then time to adapt to the new and safer coding practices.

5. Relevant resource

PS: JSLint is a debugger written by Douglas Crockford. Simply paste in your script, and it’ll quickly scan for any noticeable issues and errors in your code.

[Ref: , Mozilla Developer Network]

Resource: Stackoverflow

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA