Have you ever wondered how FORs impact your code? How they are limiting your design and more important how they are transforming your code into an amount of lines without any human meaning?

In this post we are going to see how to transform a simple example of a for (provided by Francesco Cirillio - anti-if campaign), to something more readable and well designed.

Moreover of explaining the Francesco approach, also we are going to see Lambdajapproach, which differs a bit from Francesco approach but it is effective too.

So let's start with original code using FOR:

Read Full Post Here

The solution read in the article is really orrible and unreadable!

All this mess to remove a simple for(..) cycle!?!??!

I think that a good software enigneer should solve other most interesting problems...

talk about over engineering...yikes.  I had to double check the calendar to make sure it was not April 1.

Since when replacing for() with while(iterator.hasNext()) has any added value?

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:

1) Repetition
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.