A case for for loops ➰
07 March, 2020 - 2 min read
Communication.
Lately I've developed a preference for for...loops.
The reason being that it's verbose.
I've never been a fan of commenting code and have always encouraged writing code that's self-explanatory. Generally, I reserve comments to explain why(not what) something's happening.
let your = function describe(itself) { /* without comments */ }
To achieve this, it is important to be as simple and direct as possible.
Consider this:
let numberList = [1,2,3];
let totalCount = numberList.reduce(sum, 0);
function sum(previousSum, currentNumber) {
let nextSum = previousSum + currentNumber;
return nextSum;
}
Seems relatively straight forward right?
But...
there's a condition!
You need to know exactly what reduce
does to understand what's happening.
Compare that☝ to this👇:
let numberList = [1,2,3];
let totalCount = 0;
for (let number of numberList) {
totalCount += number;
}
The second example outshines the first in terms of simplicity. One could even argue that understanding the second example is almost effortless, since it seems semantically closer to natural language(English).
This is a fairly simple example. The difference becomes clearer once it gets complex.
But of course there are drawbacks.
Afterall, a price for everything.
For...loops compel imperative programming.
I think most can agree that debugging imperative code is rarely exciting since tracking state changes can get complex very quickly.
So...
Should you change your code to use for...loops?
Of course not!
The underlying idea is to appreciate simplicity and variation. Sometimes programmers tend to sacrifice legibility for performance and/or optimization. It's not necessarily a bad thing and it really depends on what you value more.
I happen to value legibility because I appreciate the art of programming. Communication - the ability to express complex ideas and solutions as a series of understandable steps. The simpler the better.
Less is more <is>
.
Props to you if you found the title humourous.😁