4 ms·
What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use e
by wruza 4y ago
What forced me most to use DRY in inappropriate ways is typing out blocks of the same code again and again. Then I realized that and began to maintain and use easily expandable snippets with fillable placeholders. It turned out that my mind had no objections against repetitive code at all, and the clarity of it has only increased, due to the lack of context switches and parametric entanglement.
- henrydark 4y agoThis is like a compiler inlining code for faster performance, with exactly the same reasons
- erik_seaberg 4y agoWe do this because, unlike developers, CPUs can’t learn anything. No reusable abstractions are possible without extra instructions (and cycles) that tell the CPU exactly when and how to reuse them, or new microcode firmware that ordinary users aren’t empowered to write.
- ehnto 4y agoGenuinely curious, what do you do for refactors? Create a new snippet and go replace all the required instances?
- wruza 4y agoYes, e.g. when I need to add a new line/block of code, I just search for a pattern and edit there. When refactoring demands heavy structural cross-module changes, I just don’t do it honestly. What’s dead is dead, but I may do a “guided” side by side rewrite. I don’t touch snippets unless there is a good reason to do that. They are my general templates, not per-project tools. In most of my code, the need for refactoring was mostly a consequence of building a too rigid high-tech structure which with time turned out to not fit the job anyway. Figured out I can avoid it by not building it, and antiDRY also plays a role in it (albeit mostly psychological).
- ehnto 4y agoI have taken what you might consider low-DRY approach also so it's interesting to see what mechanisms people use to manage reuse without introducing complexity into the system itself. I think taking another look at project agnostic generators is something worth doing too. It has the benefits of automating some of the duplication without the rigidity of deep abstractions and dependencies. I am still exploring that though.
- xigoi 4y agoWhy not turn your snippets into actual templates?
- wruza 4y agoWhat do you mean? I’m currently using vim-snipmate.
- xigoi 4y agoI mean, if you have repetitive pieces of code that can be parametrized, why not parametrize them directly in the code instead of using a tool to produce the same code over and over?
- wruza 4y agoQuoting myself, due to context switches and parametric entanglement
- xigoi 4y agoCan you give an example where abstraction would be too complex, but a snippet wouldn't?
- wruza 4y agoE.g. I rarely abstract http calls or endpoints, because APIs tend to have nuances and to account for them I have to add more parameters than is worth. So I have a full-blown snippet from which I delete irrelevant parts. Another example is little utilities like a promise as a semaphore (by lifting resolve() to the scope). It could go as a utility function without parameters, but then I’d have to maintain that utility module across projects, which makes it extremely fragile, and force other people to deal with it.