The following is a little polished stream-of-thought inspired by Philip Winston’s Game Recognizes Game. It’s a great article about how an important finding of cognitive science applies to programming: Miller’s The Magical Number Seven, Plus or Minus Two that claims you can only handle about seven things simultaneously.
I’ve seen the following discussions crop up, mostly in code reviews, many times:
Spoiler alert: I’m usually person A.
In all these examples, person B is completely correct. It’s not that I have found a defect in their code.
Rather, I have another reason to make these comments: reducing what I think of as “noise” when reading code. It’s on me that I often haven’t been explicit and actually told people what my reason is. I pledge to improve on this. Anyway, the reason I care about code noise is that reading code takes up a massive amount of time in a developer’s work day. Therefore, even tiny improvements add up to a real difference.
OK, but am I not simply talking about the beaten-to-death horse of readability? Yes and no. When developers discuss readability, it’s usually about naming, factoring, grouping statements into logical stanzas, and many other factors. The noise I’m talking about here is yet another of these factors, one that I think hasn’t been discussed as often. It’s these little redundancies or extra expressions that are hardly worth mentioning. They change neither the correctness nor the factoring of the code. So why bother?
I believe we should bother - to a reasonable degree - to reduce cognitive load when reading code. As Philip outlines in his article, there is a hard biological limit to the number of things our brain can work with at a time. The larger the chunks of our program that fit within this limit, the easier and quicker we can understand it and reason about it.
There are two ways reducing code noise reduces cognitive load.
One way is simply due to the shrinking of code. Every simplification of code, every boolean clause and every optional argument and every word you can omit, will allow readers to parse the code faster and fit more of it into their working memory and attention spans. Mind you, I’m not advocating using shorter and more cryptic names or obscure tricks. It’s not the number of characters, it’s the number of things you need to parse.
The other way these simplifications reduce cognitive load is more important. They prevent readers “stumbling” over the code. For instance, reading a boolean expression, instead of doing this quickly and moving on, they wonder “Wait a second, isn’t that the same as <simpler expression>? Let me read this again to make sure I haven’t missed a subtlety.” Reading the expression again takes only a half a minute, but now the reader’s working memory and focus have been diverted and context is lost. The total loss of time is much greater than the time it takes to read the expression again.