What does “use strict” do in JavaScript, and what is the reasoning behind it?

Question

Recently, I ran some of my JavaScript code through Crockford\'s JSLint, and it gave the following error:

Problem at line 1 character 1: Missing \"use

Answer 1

Use Strict is used to show common and repeated errors so that it is handled differently , and changes the way java script runs , such changes are :

• Prevents accidental globals

• No duplicates

• Eliminates with

• Eliminates this coercion

• Safer eval()

• Errors for immutables

you can also read this article for the details

Answer 2

The statement "use strict"; instructs the browser to use the Strict mode, which is a reduced and safer feature set of JavaScript.

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

8. eval in strict mode does not introduce new variables

9. Forbids deleting plain names (delete x;)

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

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

12. arguments.callee is not supported

[Ref: Strict mode, Mozilla Developer Network]

Answer 3

I would like to offer a somewhat more founded answer complementing the other answers. I was hoping to edit the most popular answer, but failed. I tried to make it as comprehensive and complete as I could.

You can refer to the MDN documentation for more information.

"use strict" a directive introduced in ECMAScript 5.

Directives are similar to statements, yet different.

• use strict does not contain key words: The directive is a simple expression statement, which consists of a special string literal (in single or double quotes). JavaScript engines, that do not implement ECMAScript 5, merely see an expression statement without side effects. It is expected that future versions of ECMAScript standards introduce use as a real key word; the quotes would thereby become obsolete.
• use strict can be used only at the beginning of a script or of a function, i.e. it must precede every other (real) statement. It does not have to be the first instruction in a script of function: it can be preceded by other statement expressions that consist of string literals ( and JavaScript implementations can treat them as implementation specific directives). String literals statements, which follow a first real statement (in a script or function) are simple expression statements. Interpreters must not interpret them as directives and they have no effect.

The use strict directive indicates that the following code (in a script or a function) is strict code. The code in the highest level of a script (code that is not in a function) is considered strict code when the script contains a use strict directive. The content of a function is considered strict code when the function itself is defined in a strict code or when the function contains a use strict directive. Code that is passed to an eval() method is considered strict code when eval() was called from a strict code or contains the use strict directive itself.

The strict mode of ECMAScript 5 is a restricted subset of the JavaScript language, which eliminates relevant deficits of the language and features more stringent error checking and higher security. The following lists the differences between strict mode and normal mode (of which the first three are particularly important):

• You cannot use the with-statement in strict mode.
• In strict mode all variables have to be declared: if you assign a value to an identifier that has not been declared as variable, function, function parameter, catch-clause parameter or property of the global Object, then you will get a ReferenceError. In normal mode the identifier is implicitly declared as a global variable (as a property of the global Object)
• In strict mode the keyword this has the value undefined in functions that were invoked as functions (not as methods). (In normal mode this always points to the global Object). This difference can be used to test if an implementation supports the strict mode:

var hasStrictMode = (function() { "use strict"; return this===undefined }());

• Also when a function is invoked with call() or apply in strict mode, then this is exactly the value of the first argument of the call()or apply() invocation. (In normal mode null and undefined are replaced by the global Object and values, which are not objects, are cast into objects.)

• In strict mode you will get a TypeError, when you try to assign to readonly properties or to define new properties for a non extensible object. (In normal mode both simply fail without error message.)

• In strict mode, when passing code to eval(), you cannot declare or define variables or functions in the scope of the caller (as you can do it in normal mode). Instead, a new scope is created for eval() and the variables and functions are within that scope. That scope is destroyed after eval() finishes execution.
• In strict mode the arguments-object of a function contains a static copy of the values, which are passed to that function. In normal mode the arguments-object has a somewhat "magical" behaviour: The elements of the array and the named function parameters reference both the same value.
• In strict mode you will get a SyntaxError when the delete operator is followed by a non qualified identifier (a variable, function or function parameter). In normal mode the delete expression would do nothing and is evaluated to false.
• In strict mode you will get a TypeError when you try to delete a non configurable property. (In normal mode the attempt simply fails and the delete expression is evaluated to false).
• In strict mode it is considered a syntactical error when you try to define several properties with the same name for an object literal. (In normal mode there is no error.)
• In strict mode it is considered a syntactical error when a function declaration has multiple parameters with the same name. (In normal mode there is no error.)
• In strict mode octal literals are not allowed (these are literals that start with 0x. (In normal mode some implementations do allow octal literals.)
• In strict mode the identifiers eval and arguments are treated like keywords. You cannot change their value, cannot assign a value to them, and you cannot use them as names for variables, functions, function parameters or identifiers of a catch block.
• In strict mode are more restrictions on the possibilities to examine the call stack. arguments.caller and arguments.callee cause a TypeError in a function in strict mode. Furthermore, some caller- and arguments properties of functions in strict mode cause a TypeError when you try to read them.

Answer 4

A word of caution, all you hard-charging programmers: 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.

My project was not a greenfield project when I adopted "use strict". As a result, my IDE is full of red marks because I don't have "use strict" on half my modules, and JSHint complains about that. It's a reminder to me about what refactoring I should do in the future. My goal is to be red mark free due to all of my missing "use strict" statements, but that is years away now.

Answer 5

"Use Strict"; is an insurance that programmer will not use the loose or the bad properties of JavaScript. It is a guide, just like a ruler will help you make straight lines. "Use Strict" will help you do "Straight coding".

Those that prefer not to use rulers to do their lines straight usually end up in those pages asking for others to debug their code.

Believe me. The overhead is negligible compared to poorly designed code. Doug Crockford, who has been a senior JavaScript developer for several years, has a very interesting post here. Personally, I like to return to his site all the time to make sure I don't forget my good practice.

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.

Answer 6

Including use strict in the beginning of your all sensitive JavaScript files from this point is a small way to be a better JavaScript programmer and avoid random variables becoming global and things change silently.