Avoid using this keyword

Rules and Languages
,
1

As Douglas Crockford states it: this is unsafe, and should not be used.

I would love to have this rule. (Just as I like to have Avoid the use of null)

3

It should be kept in mind that creating a closure for every instance and accessing state from there is much slower than using a single function object and accessing state from this (if there is more than one instance). This is not only because of creating the closures (memory) but also because the calls to them will be polymorphic, so the engine has a harder time optimizing. Doing this in a single place tends to be insignificant but doing it all over the app slows it down in a way that cannot be fixed by optimizing hot spots.

So without this, calls should look like someFunction(obj1, obj2) most of the time and not like obj1.someFunction(obj2). This is unfortunate because it is quite useful to have the type of obj1 as context when deciding (while coding) which someFunction to call.

A better approach would be to forbid only the unsafe parts of this. TypeScript’s noImplicitThis goes a long way towards this, but has some holes, like:

class C {
  x: number;
  constructor(x: number) {
    this.x = x; // OK
  }
  square(): number {
    return this.x * this.x; // OK
  }
}

const c: C = new C(2);
const area = c.square(); // OK
const f: () => number = c.square; // Not OK, but TypeScript doesn't complain
f() // Called without a valid `this`
1 Like