I don’t quite get the point of article. It essentially boils down to:
“Abstractions — or rather, indirections — are bad for for readability, but they are good in some cases.”
Umm... this can be said for pretty much anything. Over use of anything is bad. Inappropriate use of anything is bad.
> Mostly, I want authors to be aware that there is a human cost to indirection that is felt more acutely by everyone reading the code except the original author.
Sure. It’s a well known fact that abstractions have associated costs — nothing new there. However, the author seems to forget that not abstracting things can be equally costly — even when human readability is concerned.
Imagine someone trying to figure our the business logic be reading code. All they need to know is some conditions are being met for certain steps to be executed. The actual steps involved in the check are irrelevant to the business logic. The condition can be modelled separately from the business logic and can even change independently. For example:
def is_foo_condition_satisfied((self):
return self.variable.startswith(‘foo’)
In this case, it just happens that the satisfaction of a condition is implemented as prefix check. In the future, it might be changed to checking a flag or reading a database, or anything really. If you sprinkle the startswith() check all over you code, it will be hard to make the change. And it actually hurts readability. While reading a large codebase, you want to focus on specific parts of it — getting into the details of everything all at once does not make it easier.
The most important thing to note is — programming is not confined to s strict set of rules. It’s not an exact science. You can’t define a strict a rules that must be followed. What makes sense somewhere is completely useless elsewhere. The Linux Kernel is full of goto statements, despite the fact that goto is considered harmful.
Dogma Driven Programming must be avoided. Even well known programming practices are guidelines at best. One must evaluate whether a given rule fits a given situation.
Coming back to the example at hand, functions are meant to divide the program by the logical tasks being performed, not by number of lines or any other metric. As I said before, it’s more art than exact science.
Is the check for foolikeness of something a logically distinct task? It depends on the context. There is no way to write a cardinal rule either way.
PS. I sincerely hope no one comes to me for code review with a monolithic function because of all the inlining — citing this article as inspiration.
Edit: Typo correction.