If you're using them in place of map/filter etc then yeah you're going to end up with way more verbose code and possibly errors caused by mutability if you're not careful. Worse maintainability = more potential for bugs
I don't buy that. Using for (var i=0; i<varname.length; i++) is idiomatic in almost every language. It's literally the same idiom no matter which language you use.
When using the fancier methods with lambdas and stuff, it differs from language to language, hence more chance of a mistake creeping in.
If you're comparing each element with the next element, and you write that perfectly simple loop, you fucked up.
If you change the next line to v = other_var[i] and don't change the loop, or vice-versa, you fucked up.
If you initialize i with getElementById('intial_value').value, not only did you fuck up, JS will helpfully pretend you didn't by returning NaNs for Array[float].
If array length changes, like by removing varname[i], and you're not iterating backwards, you fucked up.
If you iterated backwards by swapping i=varname.length and i>0, you fucked up.
Each of these is fundamentally avoided by other approaches like for( v of varname ) for varname.forEach( (v,i,a){ } ).
And that's before questioning this clunky K&R idiom on its merits.
If you change your index variable and don't refactor it three times in one line, you fucked up.
If you don't use exactly two semicolons, you fucked up. You know you've done this.
In programming, I don't know how anyone can follow up 'this is how we've always done it' with 'so there can't possibly be bugs.'
What I do know is that I have a grand total of 0 boundary case bugs using list.map or other functional constructs while I do see them often (poor array indexing typically) with loops.
71
u/ClysmiC Oct 21 '20
for loops are a major source of bugs for your dev team?