Explorations in Looping
the old fashion
This loop style is great if you need an index counter. For example you need the index into an array like:
myArray[index] = newValue
This uses the Swift Range operator (three periods) - really handy!
Also 0..<myArray.count.
the modern
With this style of for loop there is less chance of indexing errors - the dreaded off-by-one just goes away!
the step counter
Typically for loops increment by ONE, but when you want to count by steps like TWOS you use a stride in Swift.
Note: the to: parameter is not inclusive!
This would output ... 1 3 5 7 9.
the filtering loop
A for loop may filter its list by adding a where clause. So, if the condition in where clause returns true, the loop is executed.
This prints... Holly Diamond Swift.
for i in 0..<10 { }
The 100 Doors Kata got me thinking deeply about for loops. And the classic programmer bane of existence is the OFF-By-ONE foot shot that looping brings up.
So I was wondering about K&R C would it allow one to write the syntax of an improperly structured for loop? For Example:
for( Int i; i < 10; i+=0 ) {
print("Classic C for loop \(i)")
}
I expect that it would... and I bet many implementations since have continued the practice of blaming the human. I'm happy to note that there is an up and coming language that addresses these issue - Zig. Then I thought surely the Zig language checks both upper and lower bounds and boundary conditions on each iteration of the loop!
But does Swift check? I will have to go check - easy with a Xcode Playground!
The score so far - Swift makes an old coder like me adopt a better syntax for looping - Since Swift 3. It could give a hint in the Error message, something like: "did you mean for index in 1 ...100 { ... }" - maybe I ask too much.
Then I went on to test the iteration options. Swift compiler caught the iterate by ZERO mistake. But not the zero to ten by negative one. Surely with all that machine learning and processing power, the compiler can detect convergence and non-convergence!
Check out Master For Loops video on the Tube.
See - Starting with ZERO is a bad decision. A discussion of the problem with Array indexes & the off by ONE errors it induces.
Martin Fowler said...
"Any fool can write computer-understandable code. Good programmers write code that people can understand." -- Martin Fowler
The obvious corollary - modern compilers can unwrap your nested loops with if trees a mile deep and optimize the hell outa that spaghetti code. So write good readable code any way you think will work. Oh - and use an optimizing compiled language. One that doesn't depend on Log4J which *surprize-surprize* has a Log4Shell vulnerability. Open source - live by the sword die by the sword.
100 Doors - a Kata
This whole topic of looping constructs came up in the exercise on TDD with Lance over at TDD.Academy. We were talking about various languages and their looping constructs - we both come from a strong C language background, so that style is our first instinct. It might not be the best - heck I'm sure it is not!
This line of thinking about why we use specific patterns got me to questioning a lot of what I do ... "naturally" (none of it is Natural). Like the Apple practice of naming singletons - it's hard for me to guess which name they will choose this time.
Then I got to pondering the nature of the SwiftUI frameworks and their usage of Declarative UX. The very nature of the ViewModel practices and why that part of this puzzle was so... Imperative in nature. What's the big difference between Imperative vs Declarative programming? I watched a lot of videos on this topic... and came away liking David Farley's talk the best. I also liked Computerphile's take on it. I starting wondering if I could better utilize the UI if I adopted a more declarative ViewModel... what would that mean? What could it look like? Would the friction drop in the actual App code?
A mash-up?
What would it take to mash-up the Cyber-dojo onto the iPhone platform via something like Swifty Compiler? Anyone?
