I must support Alex's article, the big mistake of Alex is typical these days: to classify things as "good and bad"
For loops ARE NOT BAD, the bad guy is not "for" the bad guy are:
2) No concern separation
In my opinion Alex approach is good when
you have many fors of some collection doing many different things and filtered by many different factors, in this case you realize you can refactor FOR CONCERN SEPARATION, MODELING, REUSING AND CODE REDUCTION as the main motivations (instead "avoiding fors").
Alex approach is only useful when
- you have two or more filter rules: time to make some kind of interface of base class and different implementations
- you have two or more ways of presentation: time to make some kind of interface of base class and different implementations
When you have modeled filters and presentation you can easily make some function foreach to get all together, but you are NOT avoiding "for" just because some stupid taleban guy said "is bad" (Alex replaces one "for" by two "while") or just because everything must be in functions, no, is just to reuse repetitive code and modeling (associate concepts to code).
But when you have some anecdotal fors, following approaches like this is pure over-engineering or premature-engineering. It is like coding systematic base classes or interfaces when there is not going to be more of one implementation.
This has nothing to do with anti-if campaign, the anti-if campaign is more related to misuse of inheritance and polymorphism.
Unfortunately the anti-if web site is now just a self-ad of Francesco, hard to find some educative stuff.