> You did not include variants of
>
> var i, a=[];
> for (i=0; i < 10; i++) {
> a.push(print(i));
> }
> print(a[3]); /* output is 9 */
>
> in your list. I see related bugs on a regular basis.
That would be (7). The above should work. The problem only exists with
functions (or rather, closures):
var result = [];
for (var i=0; i < 5; i++) {
result.push(function () { return i });
}
console.log(result[3]()); // 5 (not 3!)
Code for adding event handlers via a loop is often similar. Either for-of or
Array.prototype.forEach() help.
> The other place I see regular bugs by intermediate coders is related to
> 'this' in events; but I'm not sure if we can count that as a JS problem or a
> DOM bug (Is that 9c in your list?) --
>
> function A() {
> this.a = 123;
> }
> A.prototype.p = function {alert(this.a)};
> window.onclick = new A().p;
>
> IIRC, clicking will alert undefined, as the event handler is invoked with
> this as the event. IME, this is not what programmers mean when they write
> that.
>
> We can work around it by changing the constructor:
> function A() {
> this.a = 123;
> this.p = this.p.bind(this);
> }
>
> but of course now we are over-allocating for no good reason IMO. Very
> frustrating.
Yes, that’s (9c). I would love for JS to make the distinction between reading a
property and invoking a function. Then one could automatically bind if a method
is read. But that doesn’t seem to be in the cards.
> #3 on your list is entertaining, I have been told that == is faster than ===
> in at least one implementation, because that's what sunspider tests.
http://jsperf.com/equ-vs-strict-equ
It seems that strict equals is usually faster.
> On 30 December 2012 16:22, Axel Rauschmayer <[email protected]> wrote:
> [Starting a new thread, just in case.]
>
>>> I made a list of the 10 biggest JS pitfalls and most of them will be gone
>>> under ES6. Much less to worry about, much easier to learn.
>>
>> Could you share your 10-biggest list?
>
>
> 1. Both undefined and null [not too much of a problem, easily learned]
> 2. Truthy and falsy values [not pretty, but I’ve grown used to them and the
> convenient but sloppy “has a value” checks via `if`]
> 3. == [easy fix: always use ===]
> 4. Parameter handling [fixed in ES6]
> 5. Array-like objects [not completely fixed (DOM...), but `arguments` becomes
> obsolete in ES6]
> 6. Function-scoped variables [`let` FTW in ES6]
> 7. Accidental sharing of data [for-of will help in ES6]
> 8. Creating sub-constructors is messy [fixed via classes and `super` in ES6]
> 9. `this` in non-method functions:
> 9a) Referring to the `this` of a surrounding method,
> 9b) accidentally creating globals by forgetting `new`,
> 9c) using methods as callback functions
> [(a) and (b) fixed by ES6 arrow functions and ES5 strict mode]
> 10. The for-in loop [simple rule: avoid if you can, already possible in ES5]
>
> Thus: 1-3 won’t go away soon. 4-10 are mostly eliminated by ES6.
>
> Deliberate omissions:
> - Implicit conversions are messy (and a superset of pitfall #2), but seem to
> surprise people much less than the above items.
> - Modules close another important hole in JavaScript, but I wouldn’t consider
> that hole a pitfall.
>
> There are more pitfalls, but these seemed the biggest ones.
>
> --
> Dr. Axel Rauschmayer
> [email protected]
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
