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 thethisobject, 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 thatselfis already in use as another pointer to thewindowobject. Don’t redefineselfas 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 namedleftto determine or set element coordinates. Once again, the problem is thattopis a host object, it points to the outermostwindowobject 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.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of Yahoo!, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
7 Comments
I would never use names like this because they always seemed too ambiguous. Generally if I’m going to call a variable by "top", I would describe it a little more. One thing I’ve struggled with, in dealing with my own naming conventions, was whether to use a prefix of suffix. With CSS, they use things like "top" as the suffix, what kind of format do you follow and why?
Andrew Herron on June 4th, 2007 at 1:38 am
Nicholas, it looks like you have been into best coding practices recently. Did you become a team lead?
Let’s get back to the post. You won’t have problems with these names if you declare them in your functions with the ‘var’ keyword. And why wouldn’t you recommend people to make a closure that will function as a namespace?
JCurtis on June 5th, 2007 at 3:35 am
I ran into two other ones…
If you make a function, you can’t pass in a parameter named "class" if you’re using IE (works fine in FF). Same thing with "event"
Sean on June 5th, 2007 at 11:08 am
@Andrew - typically I make variables with words that get more specific as they go on. For instance, if you’re dealing with the left coordinate for an element, the variable name would be elementLeft (element is the grouping, left is the specific property). I find that typically works best.
@JCurtis - I’m one of the senior members of the My Yahoo! front end team, so coding practices fall under the type of stuff I do regularly. As for using "var", that prevents name collisions but my concern is that it is confusing to appropriate a global variable name as your own. When is "self" not "self"? When preceded by "var"…by why make it that confusing? Just let "self" be what it is and use a different name.
@Sean - "event" is also one you have to be careful with, for sure, though it shouldn’t cause problems if it’s a named argument. "class" is actually a reserved word so the interpreter should pick that up as illegal.
Nicholas C. Zakas on June 5th, 2007 at 5:19 pm
Then Steve McConnell’s ‘Code Complete’ book might interest you. As for the names, ‘top’ is not very informative when it is not accessed through the ‘window’. Which top is it? I do not think it is a good idea to shadow names though, I just pointed out that it’s still possible to access them if the code was written correctly.
Thanks for the post anyway, it made me think :-).
JCurtis on June 6th, 2007 at 7:40 am
I don’t think so, because we always use ’self’ for a alias of ‘this’ in the closure, I think it has become a convention in the community.
If you want to point self, top or location of window, you should write ‘window.self’, ‘window.top’ and ‘window.location’, what is a good practice I insist on in my team. In fact, window.self is rarely used, because it just a self-reference to window object.
hax on June 28th, 2007 at 10:24 pm
@hax - This is precisely what I’m saying you shouldn’t be doing because it’s confusing. I use self all the time as a reference to the current window. Generally speaking, it’s a bad idea to redefine global variables in a local context that gives them a different meaning.
Nicholas C. Zakas on June 28th, 2007 at 11:20 pm