Rethinking JavaScript for-loops

There are betterse ways already: underscore.js(http://documentcloud.github.com/underscore/) and coffescript(http://jashkenas.github.com/coffee-script/, which also has its own underscore.coffee http://jashkenas.github.com/coffee-script/documentation/docs...). All three started by Jeremy Ashkenas (http://www.documentcloud.org/about).

While I enjoy the creativity of his for loops, javascript is the not language to be doing this in. One of the key advantages of using a foreach loop with a callback function, is that javascript has functional scope. All of those variable declarations in his for loops are just for show, so personally I think the while loops in his examples are more appropriate for javascript as it doesn't fool you into thinking it has block scope.

The feeling here seems to be that "for-loop tricks" are not a good idea, mainly because of readability. I disagree. I'm talking about the "idea" of for-loop tricks, not the specific ones shown in the article.

For-loops are used in really limited ways, but they should be used much more often. Programmer should be better versed in how for loops work, the fact that you can add multiple expressions between each semi-color (;), etc. The reason is, for-loops are the most readable constructs for looping. Here's why:

For-loops are the one loop construct which give you all the information about the looping at once. Used smartly, you can read the first line of the for-loop, and discover everything that the programmer would like to do, that has to do with the looping.

For example, adding two variables to be incremented in a for-loop is trivial: for (int i=0, int b=10; i==10; i++,b++)

This can also be done outside of the for-loop declaration, e.g. as the first line inside the for-loop. However, for smart programmers, this signals, to me, that "b" is another variable having to do with the loop that I would like incremented each time. In other words, it gives me more info.

Other good uses can include checking two conditions, checking conditions with side-effects (e.g. instead of i++, use word=read_word_from_file()), etc. Lots of people are uncomfortable with these in a for-loop, but I maintain that's the best construct for these kinds of things, since it gives you all the info you need to understand the loop at one point only.

The main point of the article seems to be that the JavaScript for construct is exactly the same as the C for construct. You get the same power, the same freedom and the same responsibility to for the love of god use something better.

Especially in JavaScript. Please stop using for loops in favour of asynchronous recursion (or similar). Thank you.

This is what I've been using lately, pretty neat: http://github.com/caolan/async

Re-thought for-loops hurt the brain. Please don't do that.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan

A neat collection of tricks, but I'm not sure I would ever actually employ any of them (except perhaps storing the length -- although I'd like to check that it makes a difference first). There just doesn't seem to be a major advantage to any of the tricks, and they all come with some cognitive cost to the reader (and in some cases greater costs, e.g. failure on arrays with falsey values).

It would have been interesting if these new recommended iteration forms were accompanied by profiling data and performance tests across the major engines. Right now it looks like variety for the sake of variety.

I sometimes find this nicer to read when I just want to collect a property from an array of objects (yes, map would work too):

    var ids = [story.id for (story in stories)]

I like some of those. Thanks!

What is a for-loop? Seems to copy my beautiful jQuery each()!

$.each(new Array(3), function(i){ alert(i); });