The problem here is that our so-called editors cannot inline calls for us.

I feel that would just hide other problems. As soon as you pull some code out into a function, it is inviting other uses of it. As soon as someone fixes the function for their use in a way that breaks it for yours...

... then your unit tests make it clear that they shouldn't do that.

Sure. That's why there are more quality-oriented practices than unit tests. Personally, I'm also a big fan of pair programming, collective code ownership, automated functional testing, good run-time monitoring, weekly retrospectives, and doing a five-whys for every bug. Even with that bugs happen, but hopefully not very many of them.

Still, when I'm worried about other programmers breaking something, I write unit tests. Library code should have good tests that document the purpose of the shared function. And my general experience is that when I break some shared library function anyhow, I'll see other tests going red. Unit tests are my first line of defense for this sort of problem.

> As soon as someone fixes the function for their use in a way that breaks it for yours...

... it becomes clear that you're actually dealing with two separate "pieces of knowledge".

Many editors let you peek at the source of a call in a pop-up window.

Even so, it sort of breaks the flow. The difference between reading a novel from beginning to end or a choose-your-own-adventure book.

In a large app, inlining all calls would be unreadable. Having sane, descriptive names for functions (and using functional programming, for that matter) solve the problem better than inlining.

We talk about cases where subject article has sense. In such cases you can't 'just give it a name', because read the article first please. Every instrument has its uses, I'm talking about that we miss it, not about what mess could be done by abusing it. Mess can be done in any language, in any editor/IDE.