views:

88

answers:

7

what is considered best-practice in this case?

for (i=0; i<array.length(); ++i)

or

for (i=array.length()-1; i>=0; --i)

assuming i don't want to iterate from a certain direction, but rather over the bare length of the array. also, i don't plan to alter the array's size in the loop body.

so, will the array.length() become constant during compilation? if not, then the second approach should be the one to go for..

A: 

for (i=0; i<array.length(); ++i) is better for me, but for (i=array.length()-1; i>=0; --i) is fastest, because common processors fastest checking condition comparing to 0 to condition comparing to two varbiales.

array.lenght() is constant if you dont adding/erasing elements from this array under iterations.

Svisstack
Fastest would depend upon the language being used
Jeff Schumacher
If you're accessing items in a zero-index array you actually want `for (i = array.length() - 1; i >= 0; --i)`.
Duracell
@Jeff could you elaborate? which languages (e.g.) wouldn't be bothered by choosing one over the other?
guest
+2  A: 

Version 2 is broken and would iterate from one past end of array to 1. (Now corrected)

Stick with version 1. It's well recognised and doesn't leave the reader doing a double-take.

spender
@Spender: Depending on the language, version 2 can still be broken! For instance, when array.Length is 0 and i is an unsigned integer. Classic integer underflow.
Moron
+1  A: 

I would do the first method, as that is much more readable, and I can look and see you are iterating over the loop. The second one took me a second :(.

array.length will remain constant so long as you arent modifying the array.

webdestroya
+1  A: 

Version 1 is far more widely used and simpler to understand. Version 2 may occasionally be very slightly faster if the compiler doesn't optimize array.length() into a constant, but...insert your own premature optimization comment here

EDIT: as to whether array.length() will be optimized out, it will depend on the language. If the language uses arrays as "normal" objects or arrays can be dynamically sized, it will be just a method call and the compiler can't assume will return a consistent return value. But for languages in which arrays are a special case or object (or the compiler's just really smart...) the speed difference will probably be eliminated.

CrazyJugglerDrummer
+1 for mention of premature optimisation. The clearest approach IS the best approach until it's found to cause problems.
spender
but `array.length()` could not be known given dynamic sized arrays
guest
A: 

In most cases I would expect array.length() to be implemented in such a way that it is O(1), so it would not really impact on the loop's performance. If you are in doubt, or want to make sure it is a constant, just do so explicitly:

// JavaScript
var l = a.length;

for (var i=0; i<l; i++) {
  // do something
}

I consider the reversed notation a "clever hack" that falls into the premature optimization category. It's harder to read, more error-prone and does not really provide a benefit over the alternative I suggest.

But since implementations of compilers/interpreters are vastly different and you do not say what language you refer to, it is hard to make an absolute statement about this. I would say unless this is in an absolutely time-critical section of code or otherwise measurably contributing to code running time, and your benchmark tests show that doing it differently provides a real benefit, I would stick to the code that's easier to understand and maintain.

Tomalak
A: 

For a for loop in my own code, though it's probably overkill, I got into the habit early on of writing my loops such that the length gets calculated exactly once, but the loop proceeds in the natural way:

int len = array.length();
for (int i=0; i<len; ++i) {
    doSomething(array[i]);
}

These days, though, I prefer using "for-each" facilities where they're available and convenient; they make loops easier to read and foolproof. In C++ that would be something like:

std::for_each(array.begin(), array.end(), &doSomething);
Owen S.
A: 
buildakicker