4 ms·

The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it. I just wanted to say that the behaviour of

by kremlin 11y ago

The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it. I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations

serve_yay 11y ago
Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I've personally never seen it in the wild.
- kremlin 11y ago
  the problem with using it even when you don't have falsy values is that, eventually, you're going to forget that you can't use it when you do have falsy values. You're going to get too comfortable with it, and it's not general-purpose enough. Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops
  - tracker1 11y ago
    Honestly, I'm more excited about some of the ES7 features at this point... I've given in, as much as I dislike transpiling, and using BabelJS for most of my new development, server and client-side. On the server-side async/await are worth their weight in gold... and using lambdas is very nice. I still don't like the ES6 module syntax over node/commonjs require statements though. The only thing to be really mindful of is when you browserify for the client that you don't accidentally include, for example the entire crypto library, buffer or similar shims because they can get very big, very quickly.
- pluma 11y ago
  I think nearly every JS engine now optimizes `for (...;i < arr.length;...)` -- I'm nearly 100% sure V8 does and fairly certain Firefox's and ModernIE's do as well. In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).
  - thomasfoster96 11y ago
    forEach is awfully slow compared to a for statement if you're dealing with numbers - less so with strings/objects, but it's still noticeable (like 10x whenever I've tested it at best). Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.
    - jaredsohn 11y ago
      I think a big reason to cache the array length within interviews (for cases when it isn't already cached) is that to not do so can often increase the complexity of a solution by a factor of O(n).
    - pluma 11y ago
      If you're doing number crunching, yes, don't use forEach. If you're just writing ordinary business code (i.e. in 80% of all code out there), by all means, please use forEach and friends. Besides, if you're doing number crunching in JS, you probably want to stick to ASM.js anyway.
- jaredsohn 11y ago
  >old canard about caching the length of an array when iterating over it I think there are still places where you need to do this (please correct me if wrong, or mention some other cases): - when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?) - if using strlen in C/C++ (for the latter, you should use string.length() instead).
BinaryIdiot 11y ago
Yeah and not a big fan of them saying you can do for...in on an array while casually mentioning the limitation of doing such. I would consider it far better practice to NEVER iterating over an array with for...in.
- TazeTSchnitzel 11y ago
  Is there even any guarantee it would be iterated in the correct order?
  - BinaryIdiot 11y ago
    Nope. Then again if you're doing a for...in you probably don't care about order.
wwweston 11y ago
Also seems weird that they don't mention `forEach`. (Sure, IE<9 is a caveat, but all the Array iteration methods are the easiest things to shim and if you're targeting below IE9 chances are pretty good it's not the first shim you'd be using.)
roryokane 11y ago
I improved the wording: “A nicer-looking but limited idiom is:” MDN documentation is on a wiki. You can just edit the page.

by kremlin 11y ago

serve_yay 11y ago

Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I've personally never seen it in the wild.

kremlin 11y ago
the problem with using it even when you don't have falsy values is that, eventually, you're going to forget that you can't use it when you do have falsy values. You're going to get too comfortable with it, and it's not general-purpose enough. Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops
- tracker1 11y ago
  Honestly, I'm more excited about some of the ES7 features at this point... I've given in, as much as I dislike transpiling, and using BabelJS for most of my new development, server and client-side. On the server-side async/await are worth their weight in gold... and using lambdas is very nice. I still don't like the ES6 module syntax over node/commonjs require statements though. The only thing to be really mindful of is when you browserify for the client that you don't accidentally include, for example the entire crypto library, buffer or similar shims because they can get very big, very quickly.
pluma 11y ago
I think nearly every JS engine now optimizes `for (...;i < arr.length;...)` -- I'm nearly 100% sure V8 does and fairly certain Firefox's and ModernIE's do as well. In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).
- thomasfoster96 11y ago
  forEach is awfully slow compared to a for statement if you're dealing with numbers - less so with strings/objects, but it's still noticeable (like 10x whenever I've tested it at best). Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.
  - jaredsohn 11y ago
    I think a big reason to cache the array length within interviews (for cases when it isn't already cached) is that to not do so can often increase the complexity of a solution by a factor of O(n).
  - pluma 11y ago
    If you're doing number crunching, yes, don't use forEach. If you're just writing ordinary business code (i.e. in 80% of all code out there), by all means, please use forEach and friends. Besides, if you're doing number crunching in JS, you probably want to stick to ASM.js anyway.
jaredsohn 11y ago
>old canard about caching the length of an array when iterating over it I think there are still places where you need to do this (please correct me if wrong, or mention some other cases): - when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?) - if using strlen in C/C++ (for the latter, you should use string.length() instead).

BinaryIdiot 11y ago

Yeah and not a big fan of them saying you can do for...in on an array while casually mentioning the limitation of doing such. I would consider it far better practice to NEVER iterating over an array with for...in.

TazeTSchnitzel 11y ago
Is there even any guarantee it would be iterated in the correct order?
- BinaryIdiot 11y ago
  Nope. Then again if you're doing a for...in you probably don't care about order.

wwweston 11y ago

Also seems weird that they don't mention `forEach`. (Sure, IE<9 is a caveat, but all the Array iteration methods are the easiest things to shim and if you're targeting below IE9 chances are pretty good it's not the first shim you'd be using.)

roryokane 11y ago

I improved the wording: “A nicer-looking but limited idiom is:” MDN documentation is on a wiki. You can just edit the page.