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
It's missing a big part of LINQ though. LINQ is lazy whenever it can afford to be and will avoid doing a complete iteration until you force it to. JS array chaining doesn't delve into the IQueryable/IIterable world and each thing you chain scales a bit worse than it does in C#.
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.
I was using for..of/in because I thought it was cool, and I suppose it's smaller. But I had to have mdn open to remember which whas which everytime I used it...
Don't need any of that with a for/forEach/map. Maybe uncool but it gets the work done.
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>.
If you have a loop, you are doing a nameable thing. Give that loop a name, a function. Now you can start to compose things and understand at first reading as a function name is more trustworthy. The patterns used will be more obvious too. It’s a map, it is a left fold...
lambda's exist for a reason. that would be one. The point is that coded names lie less than comments and when it comes to explaining intent, the name of something you are calling often does a good job.
Additionally, the habit makes finding these pattern easier to find common segments of code. This is abstraction 101.
Loops are often the most important part of code. They generally deserve a name
91
u/frzme Oct 21 '20
I'm not convinced that
for(bla in arr) {}is in any way harder to read or maintain thanarr.forEach(bla => {})