On: Good refactoring vs. bad refactoring

[boxed]

The dig against FP is weird since the "good refactor" also uses FP, just a built in one in JS. Which I agree is better, but mostly by being built in and idiomatic, it's still exactly as functional.

[ggm → boxed]

"I don't like this style of FP coding" ok: if you run the group and own the codebase you can enforce that. So good refactoring is style guide enforcement.

I think I over-read his dislike of FP. really the complaint is "why did you introduce a new dependency" which I am totally fine with, as a complaint. Thats not cool.

Many of his examples kind-of bury the lede. If he had tried to write an abstract up front, I think "dont code FP" wouldn't have been in it. "use the methods in the language like .filter and .map" might be.

[carlmr → boxed]

On point. Even then mentioning it used filter and map. But the bad refactor also uses filter and map. It's the exact same change of programming paradigm.

Given the text, I would have expected some minor refactor with range-based for loops (are these a thing? My JS is rusty). Where you get the advantage of map (no off-by-one indexing errors) without changing the programming paradigm.

[bobthepanda → carlmr]

you don't even need range loops.

you have forEach:

   list.forEach((item, index) => doSomething());

you also have for/of, though that doesn't have an index if you need that

   for (const item of list) { doSomething() };

which just obviates the need for index incrementing in the most common case, where you are incrementing by one until you hit the end of the list.

[watwut → boxed]

I think that was the point - the library added nothing, the same thing could be done with pure javascript.

[boxed → watwut]

If that was the point, then that paragraph needs to be rewritten badly.

[nuancebydefault → boxed]

In fact the paragraph needs _good_ refactoring

[ahoka → boxed]

It was quite obvious to me.