Zum "strict mode" wechseln

This translation is incomplete. Please help translate this article from English

Mit ECMAScript 5 wurde der strict mode eingeführt, welcher inzwischen in allen gängigen Web-Browsern (inkl. IE10) implementiert wurde. Während es einfach ist, im Web-Browser zum Strict mode zu wechseln (es genügt, die Zeile "use strict"; am Anfang des Quellcodes hinzufügen), ist etwas mehr Arbeit erforderlich, um bestehenden Code für strict mode umzusetzen.

Dieser Artikel soll Programmierern dafür eine Anleitung geben.

Schrittweiser Wechsel

Ein Design-Ziel des strict mode war, den Wechsel dorthin in kleinen Schritten zu ermöglichen. Man kann jede Datei einzeln oder sogar bis auf die Ebene von Funktionen hinunter Codestellen umsetzen.

Unterschiede zwischen nicht-strict und strict


Wird "use strict"; hinzugefügt, dann wird in den folgenden Fällen ein SyntaxError ausgelöst, bevor das Script ausgeführt wird:

  • Octal-Syntax für Integer: var n = 023;
  • Statement with
  • delete mit einem Variablennamen: delete myVariable;
  • eval oder arguments als Variable or Name eines Funktionsarguments
  • Benutzen der neuen reservierten Schlüsselworte (im Vorgriff auf for ECMAScript 2015): implements, interface, let, package, private, protected, public, static und yield
  • Funktions-Deklaration innerhalb von Anweisungsblöcken: if(a<b){ function f(){} }
  • Offensichtliche (Programmier-) Fehler
    • Mehrfache Deklaration von Properties mit demselben Namen in einem Objektliteral: {a: 1, b: 3, a: 7}
      Das triff auf ECMAScript 6 nicht länger zu (siehe Bug 1041128).
    • Deklaration mehrerer Funktionsargumente mit dem selben Namen: function f(a, b, b){}

Diese Fehler sind eine gute Sache, weil sie fehlerhaften Code offenbaren oder auch schlechte Angewohnheiten. Sie treten auf, bevor der Code ausgeführt wird.

Neue Laufzeitfehler

JavaScript used to silently fail in contexts where what was done was an error. Strict mode throws in such cases. If your code base contains such cases, testing will be necessary to be sure nothing is broken. Once again, it can happen at the function granularity level.

Setting a value to an undeclared variable

function f(x){
  "use strict";
  var a = 12;
  b = a + x*35; // error!

This used to change a value on the global object which is rarely the expected effect. If you really want to set a value to the global object, pass it as an argument and explicitly assign it as a property:

var global = this; // in the top-level context, "this" always
                   // refers to the global object
function f(x){
  "use strict";
  var a = 12;
  global.b = a + x*35;

Trying to delete a non-configurable property

"use strict";
delete Object.prototype; // error!

In non-strict, this would silently fail, in contradiction with the user expectation.

Poisoned arguments and function properties

Accessing arguments.callee, arguments.caller, anyFunction.caller, or anyFunction.arguments throws an error in strict mode. The only legitimate use case would be to reuse a function as in:

// example taken from vanillajs: http://vanilla-js.com/
var s = document.getElementById('thing').style;
s.opacity = 1;
  if((s.opacity-=.1) < 0)
    setTimeout(arguments.callee, 40);

which can be rewritten as:

"use strict";
var s = document.getElementById('thing').style;
s.opacity = 1;
(function fadeOut(){ // name the function
  if((s.opacity-=.1) < 0)
    setTimeout(fadeOut, 40); // use the name of the function

Semantic differences

These differences are very subtle differences. It's possible that a test suite doesn't catch this kind of subtle difference. Careful review of your code base will probably be necessary to be sure these differences don't affect the semantics of your code. Fortunately, this careful review can be done gradually down the function granularity.

this in function calls

In function calls like f(), the this value was the global object. In strict mode, it is now undefined. When a function was called with call or apply, if the value was a primitive value, this one was boxed into an object (or the global object for undefined and null). In strict mode, the value is passed directly without conversion or replacement.

arguments doesn't alias named function arguments

In non-strict mode, modifying a value in the arguments object modifies the corresponding named argument. This made optimizations complicated for JavaScript engine and made code harder to read/understand. In strict mode, the arguments object is created and initialized with the same values than the named arguments, but changes to either the arguments object or the named arguments aren't reflected in one another.

Change to eval

In strict mode code, eval doesn't create a new variable in the scope from which it was called. Also, of course, in strict mode, the string is evaluated with strict mode rules. Thorough testing will need to be performed to make sure nothing breaks. Not using eval if you don't really need it may be another pragmatic solution.

Strictness-neutral code

A potential "downside" of moving strict code to strict mode is that the semantics may be different in legacy browsers which do not implement strict mode. In some rare occasions (like bad concatenation or minification), your code also may not run in the mode you wrote and tested it in. Here are the rules to make your code strictness-neutral:

  1. Write your code as strict and make sure no strict-only errors (from the above "New runtime errors" section) are thrown.
  2. Stay away from semantic differences
    1. eval: use it only if you know what you're doing
    2. arguments: always access function arguments via their name or perform a copy of the arguments object using:
      var args = Array.prototype.slice.call(arguments)
      as the first line of your function
    3. this: only use this when it refers to an object you created.

See also