Bad Parts(Appendix B. of JavaScript: The Good Parts)

　　1. ==

　　JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:

　　'' == '0'          // false
　　0 == ''            // true
　　0 == '0'           // true

　　false == 'false'   // false
　　false == '0'       // true

　　false == undefined // false
　　false == null      // false
　　null == undefined  // true 

　　The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.

　　2. with Statement

　　JavaScript has a with statement that was intended to provide a shorthand when accessing the properties of an object. Unfortunately, its results can sometimes be unpredictable, so it should be avoided.

　　The statement:

　　with (obj) {
    　　a = b;
　　}

　　does the same thing as:

　　if (obj.a === undefined) {
    　　a = obj.b === undefined ? b : obj.b;
　　} else {
    　　obj.a = obj.b === undefined ? b : obj.b;
　　}

　　So, it is the same as one of these statements:

　　a = b;
　　a = obj.b;
　　obj.a = b;
　　obj.a = obj.b;

　　It is not possible to tell from reading the program which of those statements you will get. It can vary from one running of the program to the next. It can even vary while the program is running. If you can't read a program and understand what it is going to do, it is impossible to have confidence that it will correctly do what you want.

　　Simply by being in the language, the with statement significantly slows down JavaScript processors because it frustrates the lexical binding of variable names. It was well intentioned, but the language would be better if it didn't have it.

　　3. eval

　　4. continue Statement

　　5. switch Fall Through

　　6. Block-less Statements

　　7. ++ --

　　8. Bitwise Operators

　　9. The function Statement Versus the function Expression

　　10. Typed Wrappers

　　JavaScript has a set of typed wrappers. For example:

　　new Boolean(false)

　　produces an object that has a valueOf method that returns the wrapped value. This turns out to be completely unnecessary and occasionally confusing. Don't use new Boolean or new Number or new String.

　　Also avoid new Object and new Array. Use {} and [] instead.

　　11. new

　　JavaScript's new operator creates a new object that inherits from the operand's prototype member, and then calls the operand, binding the new object to this. This gives the operand (which had better be a constructor function) a chance to customize the new object before it is returned to the requestor.

　　If you forget to use the new operator, you instead get an ordinary function call, and this is bound to the global object instead of to a new object. That means that your function will be clobbering global variables when it attempts to initialize the new members. That is a very bad thing. There is no compile-time warning. There is no runtime warning.

　　By convention, functions that are intended to be used with new should be given names with initial capital letters, and names with initial capital letters should be used only with constructor functions that take the new prefix. This convention gives us a visual cue that can help spot expensive mistakes that the language itself is keen to overlook.

　　An even better coping strategy is to not use new at all.

　　12. void

　　In many languages, void is a type that has no values. In JavaScript, void is an operator that takes an operand and returns undefined. This is not useful, and it is very confusing. Avoid void.

转载于:https://www.cnblogs.com/zhtf2014/archive/2010/07/15/1778431.html