Well, call me pedantic for even discussing this and seeing this as relevant. But everybody knows that adhering coding styles make programming in a team way more pleasant and it is just way more efficient to just code and not to style! Which includes not having to think about how to style the code, though I realize that a lot of programmers have a problem adapting to coding styles.
We at uxebu basically defined that we are applying the coding guide lines of the project that we possibly contribute stuff back to. This means our JavaScript code applies the dojo coding style guide and our python stuff (we use internally) applies the django coding style guide.

But let’s look at the for-loop now.

The default

The most common usage of a for loop is the following.

Nothing spectacular here. But let’s take it apart a bit. There are two things that are commonly known that can be optimized.

1. The comparison “i<nodes.length” in line 1 evaluates the length of nodes on every iteration, if the nodes array is not modified while looping over it or the change to it is not relevant, this can be optimized.
2. Also the declaration of the variable “node” in line 2 is done multiple times, so this is just a small unnecessary thing to do.

So let’s optimize the things we just found out.

Version 2

Another step on our way was to optimize the variable declarations and reducing their count from three down to one. In some code you can then see the following.

Version 3

Actually we have already skipped a tiny step in between, very often you can see multiple var-statements as opposed to the already “squeezed” one-liner in line 1 above. The way of writing it as seen here, is reasonable if there are a couple other variables to be declared, you just need one var-statement. This will basically reduce the code size, if your minifier doesn’t already do that for you. As stated here it seems to be specified to be irrelevant to performance. So event the argument under 2. against the first version (see above) is not very strong.
Just a small side-note: the one line var-statement evaluates in declaration order, so something like this will work!

The “len” and also “x” variables contain the proper content as you are expecting. The comma-separated var-statement evaluates the assignment expression by expression and steps on to the next assignment. Therefore “len” and “x” will have the proper values 3 and 2.
But let’s go back to our for-loop.

Version 4

If the var-statement is outside the for-loop and especially if other variables (outside of the scope of the for-loop) are declared there the source code get’s blury and harder to read. For example:

The first two variable declarations (someVar and anotherVar) have nothing to do with the for-loop context, but the others do, so this blurs the source code and is prone to errors. Also if you separate this source code onto multiple lines like so:

it is still a possible point of failure. I for example, forgot the comma on line 1 which made this source code

still work. But and this is a big but, the code get’s a different meaning now! First, line 1 will work, since the semicolon at the end of the line is not mandatory. And second (if not declared inside this scope before) the variables on line 2 are now defined in global scope. And that can really cause a hard to find bug!
Another good reason for not doing this, is that extending the code may lead to developers adding code in between the var-declaration and the for-loop, for whatever reason. Then the variable declarations for the for-loop “drift away” and loose their context even a bit more. And the source code becomes harder to understand.

So we rather put all the variable declarations into the for-loop’s var-statement. Like so:

Now we have a pretty compact and well context-focused syntax for declaring variables needed within a for-loop. This code is nicely readable and has no impact on performance, even if in most cases good and maintainable code is worth more than the fastest code, but that’s a use case based decision! We are taking this as a standard for uxebu code.

What do you think? Let us know if you see potential for optimization.