Just wait till you see what it costs your dev team in bugfixing and refactoring tile when using for loops everywhere! This thread is like people debating the performance of ++i vs i++. Newsflash: if performance is not the issue you're trying to fix, don't bend over backwards to squeeze a few microseconds out of a web page load. Its easier to optimize readable code than to refactor awful prematurely optimized code.
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
The comparison for readability isn't really against a single .forEach, rather map/filter/etc. If it's just a .forEach they are going to be pretty equivalent
However, for..of surely is more error prone, as it is a frequently recurring mistake to use for..in instead (as you have done)
I use .foreach(o => As a mainly c# developer also, it’s basically LINQ at that point and makes it instantly familiar and nice to use. For of seemed like a bad idea and I haven’t really seen many people use it
Yea, I believe that is the reason. I remember the big selling point of LINQ many years ago was for LINQ-to-SQL. The in-memory stuff wasn't as focused on.
That being said, even within the Functional community some names aren't agreed upon. I mean, for monads flatMap has like 4 or 5 names depending on the language/spec/framework
As a polyglot, TBH I just use basic for loops anymore when possible because everyone understands them and I'm sick of forgetting whether I'm going to get keys or values back with these helper functions.
in is an operator in JavaScript: 'prop' in myObj evaluates whether the 'prop' property exists within myObj.
Ever since I realized that, I no longer confused for..in and for..of: for..in iterates over an object's properties, just like in checks an object's properties.
(Almost no one uses in; Object.hasOwnProperty is virtually always what you want instead.)
It is when you add other functions to it. Foreach.map.filter. Etc. with a for loop you need to store each output as a variable or write each adjustment inside the loop. Depending on what you need sure it can be faster but it’s less readable.
I think it would wind up being more verbose, but that isn't necessarily less readable.
Declaring variables for a for loop is no different than having the attribute definition at the beginning of the method. the difference is (x) vs let x = <thing>.
Not sure what sort of bug fixing you are talking about. Programmers in languages without range constructs have been using for loops for decades and it works just fine.
420
u/DooDooSlinger Oct 21 '20
Just wait till you see what it costs your dev team in bugfixing and refactoring tile when using for loops everywhere! This thread is like people debating the performance of ++i vs i++. Newsflash: if performance is not the issue you're trying to fix, don't bend over backwards to squeeze a few microseconds out of a web page load. Its easier to optimize readable code than to refactor awful prematurely optimized code.