JavaScript variable names you shouldn’t use

One of the biggest maintainability problems in any language has to be the correct and consistent naming of variables, classes, and methods. In most languages, keywords can’t be used as identifiers, so there’s always a warning if you attempt to do something dumb. JavaScript has keywords and reserved words that can’t be used as identifiers, but there’s also a number of host objects that exist and can be overridden without any warning.

So, quite simply, here’s a list of variables names you should never use because they are host objects in JavaScript and should never be redeclared:

  • self – I see this a lot when setting a pointer to the this object, such as: var self = this;. Oftentimes, this is how developers are keeping a reference to an object for use inside of a closure. The problem is that self is already in use as another pointer to the window object. Don’t redefine self as something other than what it is as it could confuse others looking at your code. (proof)
  • top – This one is most often used in combination with a variable named left to determine or set element coordinates. Once again, the problem is that top is a host object, it points to the outermost window object and is most useful when used from within a frame. (proof)
  • location – I’m surprised, but I have seen variables with this name. This is a host object containing information about the page that is currently loaded. (proof)

Again, these are variables names that should never be used. When people expect variables with particular names to behave a certain way, it’s always dangerous to change their behavior. You might as well just start redefining methods on the window object.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.