4 ms·
The problem likely isn't DRY, the problem here is poor abstractions.
by blazespin 10y ago
The problem likely isn't DRY, the problem here is poor abstractions.
- wruza 10y agoThe problem here is that our so-called editors cannot inline calls for us.
- smt88 10y agoMany editors let you peek at the source of a call in a pop-up window.
- wvenable 10y agoEven so, it sort of breaks the flow. The difference between reading a novel from beginning to end or a choose-your-own-adventure book.
- smt88 10y agoIn 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.
- wruza 10y agoWe 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.
- taeric 10y agoI 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...
- wpietri 10y ago... then your unit tests make it clear that they shouldn't do that.
- taeric 10y agoStatistically, relying on tests to cover areas of the code that you are not actively working on is not a reliable methodology. That is, yes, ideally you have a test catch something. Realistically, you don't have 100% test coverage.
- wpietri 10y agoSure. 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.
- dllthomas 10y ago> 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".