4 ms·
I think there's a mistake in the first example, it talks about for-in being bad but the example doesn't actually use for-in. > There is no really good reason t
by benjoffe 15y ago
I think there's a mistake in the first example, it talks about for-in being bad but the example doesn't actually use for-in.
> There is no really good reason to predefine the array length.
There are good reasons, though they're usually quite 'sneaky', for example:
function repeatString(str, howMany) {
return new Array(howMany+1).join(str);
}
> 13. Usage of undefined as a variable... that variables isn’t read-only, and any other code can change its value... why take the risk?
There's no good reason to be that paranoid, libraries could also overwrite 'document', 'XMLHttpRequest', 'setTimeout' and a number of other variables that would likely break my code; if any of my libs are so rogue that they overwrite 'undefined' then I've got big problems.
- elliottcarlson 15y agoBesides the first example having a mistake, their suggested solution still isn't best practices; for (var i = 0, len = myArray.length; i < len; i++) { ... } Will perform far faster than doing the comparison on each iteration. Might not be noticeable on an array of 10, but certainly would be on an array of 1k.