7 ms·
I agree with this important article. In the large open source project I work on, we have a prolific contributor who is systematically going through the entire
by raymondh 10y ago
I agree with this important article.
In the large open source project I work on, we have a prolific contributor who is systematically going through the entire code base, "refactoring" some of it in way the impairs my ability to read, understand, and maintain the code (even code that I originally authored). Over time, we've added scores of new macros -- as result ordinary C knowledge is now insufficient to read and understand what the code is doing.
As the author suggests, the guiding principle should be factor only when it results in a net reduction of complexity. In some cases, the cost of adding new abstractions outweighs the gains from Don't Repeat Yourself.
There is some value in having some blocks of code that can be read in isolation, even if there some bit of repetition between blocks.
- blazespin 10y agoThe 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".
- dboreham 10y agoMuch damage is done by people with too much time on their hands.
- z3t4 10y agoWhat most programmers knowing a particular programming language has in common is that they know the built in and standard library functions. So it's often better to use those, then abstracting them away under different names.