JavaScript The Complete Reference (2012)
APPENDIX JavaScript Reserved Words
All languages, including JavaScript, have numerous reserved words that cannot be used as variable names, function names, or any other form of identifiers without causing some problem. If one of these reserved words is used as a user-defined identifier, such as a variable or function name, it should result in a syntax error. For example, the following declares a variable called for, which, as you have seen, is a JavaScript keyword used for looping:
You should expect some form of error to occur if you misuse the reserved identifier:
Generally speaking, reserved words are reserved from use because they already have a defined meaning in some variant of JavaScript or a related technology. According to the ECMAScript specification, reserved words include keywords (such as switch, while, and for), future reserved words (such as abstract, class, and const), and three type-related literals (null, true, and false). The complete list according to ECMAScript 3 is shown in Table A-1.
Table A-1 ECMAScript Edition 3 Reserved Words
ECMAScript 5 does not change the list that much, adding debugger to the keywords group, reducing the list of the future reserved words, getting rid of a few unlikely values (byte, goto, and so on), but then adding in a few new ones (let and yield), given their existing implementation in some versions of JavaScript. The list according to ECMAScript 5 is shown in Table A-2.
Table A-2 ECMAScript Edition 5 Reserved Words
We note that ECMAScript has reserved values so that when a browser that supports “use strict” encounters some identifiers, it should throw errors on usage that traditionally may be allowed. For example, this should be fine:
while the following should throw an error, or at least not perform the assignment:
Reserved Quirks
Now, a read of the ECMAScript specification gives no direct indication that future reserved words are any different than regular reserved words. In fact, it seems quite clear that the specification defines identifiers to include all allowed identifier names but not “ReservedWord” grammar, which includes all the items in the previous tables. Unfortunately, testing reveals that browsers are all over the place in terms of how reserved words are treated. Each browser treats the list of reserved words a bit differently, and many allow reserved values as variable, function, or property names when they shouldn’t, particularly in the case of the “future reserved words,” as those may work now but will break in future browser releases. For example, imagine if you had a bit of code that tried to use a reserved word illegally—for example, as a variable:
If you try this, it likely will fail because most browsers will happily let the future reserved word enum be used as a variable. If you try another value, such as break, it will properly catch it.
NOTE You may wonder why we did it this way, using an eval(). The reason is that most JavaScript parsers will correctly catch the assignment of keywords when used as literals, but this doesn’t hold for most “future reserved words.” To leave nothing to chance, we should attempt to use every string, and eval() allows an easy method for that. Obviously, this will not work in a “strict” mode, so proceed with caution.
We could expand this type of code to test each word using an array. Figure A-1 shows a simple example of two browsers providing noticeably different keyword handling. If you are curious, you can use the example code displayed in Figure A-1 yourself to see the state of your browser. Hopefully, by the time you run it, things will be a bit more consistent.
Figure A-1 Potential browser inconsistencies with reserved words
ONLINE http://javascriptref.com/3ed/AppA/reservedwords.html
Beyond browser implementation details, JavaScript has further challenges with misused identifier names because the host environment may have numerous built-in objects and functions. For example, ECMAScript defines global functions such as parseInt(), parseFloat(), and type objects such as Math, Date, String, and so on, which should be considered off limits as identifier names. Similarly, any of the properties of the browser’s host Window object, such as location, name, and so on, could easily be redefined and should be avoided. Given the dynamic nature of JavaScript, misusing environmentally defined objects or functions typically won’t throw an error, but it certainly may produce an unintended result if done accidentally. Of course, people often redefine browser or document objects or other built-in functions on purpose, but that has its own downsides.
Finally, readers may find it interesting that the ECMAScript specification initially indicated that naming of user-defined variables should avoid the $ character:
Section 7.6, ECMAScript 3rd Edition:
“The dollar sign ($) and the underscore (_) are permitted anywhere in an identifier. The dollar sign is intended for use only in mechanically generated code.”
Of course, we know via jQuery and other practical applications of JavaScript that what the specification says in detail and what folks actually do may be two different things. Today, the ECMAScript 5 edition no longer continues such verbiage, likely as a concession to common usage. If such things can change, we really can’t tell what future may be in store for the “quasi” reserved words we presented or how the specification may evolve. To write future-proof code, you should assume that anything we list in this appendix is fully reserved, regardless of browser implementations.