--- title: "Iterating over collections - As simple as possible, but no simpler." url: "https://osherove.com/blog/2004/2/21/iterating-over-collections-as-simple-as-possible-but-no-simp.md" canonical: "https://osherove.com/blog/2004/2/21/iterating-over-collections-as-simple-as-possible-but-no-simp.html" published: "2004-02-21T22:24:00" updated: "2004-02-21T22:24:00" tags: [".Net Original"] author: "Roy Osherove" description: "Weekend was amazing. 'Nuff said. Now for something completely different. Julie asks why not allow VB.Net developers have an easier and shorter syntax to use when iterating over collections: For Each cust as Customer in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Iterating over collections - As simple as possible, but no simpler. By Roy Osherove February 21, 2004 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published February 21, 2004; technical details may be outdated. Weekend was amazing. 'Nuff said. Now for something completely different. [Julie asks](http://www.julialermaninc.com/blog/PermaLink.aspx?guid=a750c076-94e8-4798-aba6-de7ef4dc1e64) why not allow VB.Net developers have an easier and shorter syntax to use when iterating over collections: **For Each cust as Customer in Customers  ... Next** _Why stop there?_ _Why do I even have to (re-)define what the objects in Customers are?_ _Why can't I just write_ _**for each whateverthehecktheobjectsareinmycollection in Customers  ... next**_ _and have .net look at that and say “well d'uh, I know what **whateverthehecktheobjectsareinmycollection** is going to be because Customers is filled with Customer objects, so I will just implicitly cast the **whateverthehecktheobjectsareinmycollection** to a Customer._ _?_ Well, if you did that you would lose the ability to use _polymorphism_, or, it would be too hard for the compiler to do for you. For example, You have a collection of objects that all implement 2 interfaces: _IAnimal_ and _ICarnivore_. Say that your collection is of strongly types with "_IAnimal_" but what you _really_ want to do is loop on all _ICarnivor_s in the collection and operate on their methods. How do you tell the compiler to do that? A solution would be to say "OK, you can use the old syntax **or** the new syntax,. With the new syntax the object defaults to whatever the collection is of (_IAnimal_ in this case). But that leads to **less readable code** (Remember what happens in VB6 when you declare something without specifying a type? It's a **variant**. And find me a good developer that says its OK to declare a variable as variant simply by omitting the type at declaration. None. It's simply less readable.)  The code in question is less readable because now the developer reading the code needs to look **inside** the loop to find out exactly what is the type of the iterator variable and how its going to be used. So, you're back to square one. It's more readable (and developer friendly) to declare what type(or interface) you're iterating for. Better readability is simply a side effect. The real benefit is the ability to use polymorphism of many different types over the same collection. PS The same claim can be said about the C# iteration syntax, where you also define the type of the iterator. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Feb 22, 2004 ### [.Net user group review: BizTalk rules engine](https://osherove.com/blog/2004/2/22/net-user-group-review-biztalk-rules-engine.html) - Feb 22, 2004 ### [\[Book\] Writing Secure Code, 2nd Edition](https://osherove.com/blog/2004/2/22/book-writing-secure-code-2nd-edition.html) - Feb 19, 2004 ### [Mortal sin: Just "Doit"](https://osherove.com/blog/2004/2/19/mortal-sin-just-quotdoitquot.html) - Feb 19, 2004 ### [Mortal sin: A non-relational relational database.](https://osherove.com/blog/2004/2/19/mortal-sin-a-non-relational-relational-database.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/