I'll be honest I tend to do the latter for out of habit, and I agree
with Mark it's no more difficult to read.
var arr = [1, 2, 3, 4];
for (var i = 0, length = arr.length; i < length; ++i) {
console.log(arr[i]);
}
It does benefit from being slightly more performant for large
iterations, but at the end of the day we should write the code that
feels the most natural to us. Note I also use ++i over i++ because
it's slightly faster on some modern browsers but mostly out of habit.
Rob
On Feb 18, 3:54 pm, Mark McDonnell <[email protected]> wrote:
> As far as readability is concerned I personally don't find it confusing or
> any harder to read, but like you say, the more you use the syntax the more
> accommodating it appears.
>
> Also, as per any discussions on performance, caching the length of an array
> may not seem like a big time save until you have a massive array to loop
> through (or maybe a 'live' DOM HTMLCollection). If you know your array is
> only a few items long then sure not caching the length is no great shakes,
> but for something that effectively adds maybe 5 or so extra characters worth
> of typing could save you processes then I'm all up for that.
>
> What I don't dig is any time you have to make massive changes to how your
> code is architected when it only improves performance by a tiny margin -
> array length caching is a 1 second tweak so I see it as a something very
> feasible/affordable in a project.
>
> Anyhoo, this will likely spark more back and forth discussion I'm sure :)
>
> Kind regards,
> Mark
>
> On 18 February 2011 15:36, Nick Morgan <[email protected]> wrote:
>
>
>
>
>
>
>
>
>
> > On 18 February 2011 15:12, Mark McDonnell <[email protected]> wrote:
>
> >> Have a read of this
> >>http://blog.getify.com/2011/02/pre-maturely-optimize-revisited/by
> >> @Getify where he talks about 'im/mature' optimisation and his thoughts on
> >> this discussion.
>
> >> Personally, I think that it's such a minor tweak that I will always cache
> >> the array length. Why wouldn't you? It doesn't make the code un-readable,
> >> it's obvious to any level developer what's happening (i.e. it's not some of
> >> the more cryptic 'micro-optimisations' that you can see sometimes), and it
> >> does have a testable impact on performance if you don't do it. So (to me)
> >> it
> >> seems like an easy choice to just go with caching the length.
>
> >> Kind regards,
> >> Mark
>
> > Thanks Mark, all good points, and a good read. However, in that blog, he
> > does specifically say:
>
> > Also, notice: I am *not* focusing on esoteric and minute
> > micro-performance details (as some do, and many assumed I was). I made no
> > mention of things like array.push() vs. array[array.length], or str +=
> > "..." vs. str = arr.join(), or ++i vs. i++, or for (i=0; i < arr.length;
> > i++) {...}vs. for (i=0, len=arr.length; i<len; i++) {...}, etc etc etc.
>
> > My feeling is that it does reduce the readability slightly, and I'm not
> > sure whether that's worth it when i *know* it's not going to affect
> > performance.
>
> > Then again, if I got used to using it consistently, the readability issue
> > wouldn't be so big a deal.
>
> > --
> > Nick Morgan
> >http://skilldrick.co.uk
> > @skilldrick <http://twitter.com/skilldrick>
>
> > --
> > To view archived discussions from the original JSMentors Mailman list:
> > http://www.mail-archive.com/[email protected]/
>
> > To search via a non-Google archive, visit here:
> >http://www.mail-archive.com/[email protected]/
>
> > To unsubscribe from this group, send email to
> > [email protected]
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
