5 ms·
DRY is probably my least favourite programming meme. There are far too many overzealous juniors who learned it and have a bee in their bonnet about creating abs
by dkdbejwi383 4y ago
DRY is probably my least favourite programming meme. There are far too many overzealous juniors who learned it and have a bee in their bonnet about creating absurd abstractions around any two lines of code (or config) that have vague or imagined similarities, locking in all sorts of annoying indirection.
- physicles 4y agoFor best results, set your DRY dial to 8 or 9 out of 10. Settings higher than 9 result in premature or excessive abstraction. But if you hate DRY so much, imagine a word where people set it to 1 or 2. I wouldn’t want to work in that code base.
- swader999 4y agoWhatever you do, never turn it up to 11,
- zambal 4y agoBut what if you just need that extra bit of dryness and you're already at 10?
- fendy3002 4y agoheck, sometimes even 7 is better than 9
- postalrat 4y agoOften the best way to DRY something if to let it sit in the sun a while where everyone can see it.
- m_mueller 4y agoTotally agreed. I've tried explain exactly this issue in a talk [1], trying to find a useful synthesis between different paradigms like KISS, DRY and YAGNI. [1] https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsIG11ZWxsZXIga2lzcyBkcnk%3D https://www.youtube.com/watch?v=0FIZn2trkoA&pp=ygUXbWljaGVsI...
- gonzo41 4y agoI asked everyone's favorite chat AI to come up with a new buzzword using the letters from those. The best was KINDergartener (uses all the letters). I would describe this as a programming paradigm for people who are new to the programming and real work and havn't found out that the getting shit done and shipping the code to users is the most important state for code to be in.
- dathinab 4y agoThe trick is to understand this paradigms, why they came to be and what they want to archive and as much important when to not apply them. Then program with the things you have learned in mind, instead of blindly following the some "paradigms rules", 'cause that's never ending well.
- Symmetry 4y agoI made a DRY/YAGNI yin/yang sticker for my laptop a little while ago. https://i.redd.it/16qm2a3m7m991.jpg https://i.redd.it/16qm2a3m7m991.jpg
- IshKebab 4y agoI put it second behind "premature optimisation" which is used to justify never caring about performance at all (until it's too late and you can't do anything about it).
- DarkWiiPlayer 4y agoActual premature optimisation is harmful for the same reason as premature abstraction. In both cases, improvements that come "for free" should be done without thinking, but one they start to impact readability, we should consider how beneficial those changes really are.
- marcosdumay 4y agoIf you don't know what you are building, any action is premature.
- laerus 4y agoDRY only paired with the rule of three (or more)
- carlmr 4y agoThat, or the code block is sufficiently big and similar. I remember a ex-colleague of mine who copied a 1000 line function, changed a parameter, and didn't see anything wrong with it.
- leidenfrost 4y agoWhy do you have a 1000 line function in the first place? Sounds like an entire class of methods in a single structure.
- sodapopcan 4y agoI had a coworker who did similar. It was essentially the entire frontend for an order application (back in the jQuery days), a few thousand lines. That was all copy/pasted, changed to deal with the case of when there are no orders (which only ever happens once since this was an in-house system) and those massive chunks were wrapped in an if/else.
- bcrosby95 4y agoI recently had a junior copy paste a 20 line code block rather than add an extra 'or' to the if statement. Hey, rule of 3 ;) Anyways, guidelines are just guidelines, regardless of what you come up with you can break it.
- leidenfrost 4y agoThe worst part of DRY is that developers worrying about the amount of characters in a source file rather than readability, as if the compiler had a hard time reading those extra few kbs.
- deleted 4y ago[deleted]
- orbz 4y agoBut remember you have to get WET (write everything thrice) before you get DRY. I apologize for my dry humor.
- el_oni 4y agoTrue, but then you also get times when somebody who should know better implements a "in current financial year w/ special cases" function 3 times. Then your tester says it isn't correct in 2/3 places, you find out you've only updated the function in 1 place and either abstract those the other 2 cases out or update it in those 2 places aswell.
- _0ffh 4y agoSeems whenever someone popularizes a rule of thumb, expressed in a catchy way, some newbies will take it as inviolable absolute law that everything else must be bent around, at any cost.
- andrewingram 4y agoMy take is that all this WET/DRY wisdom makes people think about abstractions in the wrong way -- it makes us debate them in term of when, rather than what and why. In my mind, the point of abstraction is to transform models such that we can build solutions in a way that is a better fit for the problems at hand. Reducing LOC and repetition is explicitly not the goal, sometimes a good abstraction may actually result in more lines of code (but more often it's less). So reducing LOC and repetition is commonly a happy byproduct, rather the reason we do it in the first place. I see slightly more experienced programmers rebound from DRY to a point of having a pathological distaste for abstractions, and I find those codebases to be far more stressful to work in than ones which just happen to have a few bad abstractions.
- zelphirkalt 4y agoI agree with rather having good or correct abstractions than saving LOC. However, a bad abstraction can give readers/devs the wrong idea about what is behind it, how it works or how it can be used and when to rely on it. Unreliable abstractions are terrible. Leaky abstractions are also terrible. Both introduce a lot of mental load overhead.
- erik_seaberg 4y agoSome people choose “no abstraction” over “poor abstraction,” which I don’t understand. Working without any abstraction is the same as working with an infinitely leaky abstraction.
- andrewingram 4y agoYeah. A pervasive poor abstraction can be painful, but in my own experience most misguided abstractions tend to be somewhat superficial and easy to unwind. It does worry me to see so much rhetoric in the wider programming community encouraging people to avoid abstractions, because this is the kind of lesson that is easy to imprint on newcomers -- but I suspect the easiest way to get good at them, is to do them badly a few times.
- tcfhgj 4y agoFor me DRY is one of the most important principles for maintainable software. Imagine having to fix a bug at two independent places or having to add or change the same conceptual functionality at two different places (which you may not even be aware, because you don't remember you copied code somewhere else once) Totally unnecessary bugs guaranteed, and ready to be thrown away after some time, because a change will be harder than a rewrite. It's enough pain when the effort is too big to avoid (e.g. Js frontend, Rust Backend) it. Juniors will learn the difference between actual and imagined similarities at some time.
- orthoxerox 4y agoPremature dryness is the real issue, not the principle itself. When you catch yourself fixing the same code in multiple methods again, it's a good time to stop and refactor.
- glanzwulf 4y agoFunny enough this happened to me yesterday. I had to do a small change of code in a component and then when I pushed the code I got an error back. After searching for what was happening, it was actually a code I copied and named "Component2" two years ago when I was starting out. Today I would not have made it the way I did, but in my first month... And thank god for github actions! :D
- MoreQARespect 4y agoIt is fundamental but it's in constant tension with other principles - e.g. cohesion and coupling. I'm pretty sure all of the most fundamental principles of good code are in tension with each other.
- senbrow 4y agoDRY should really be "DRA" - don't repeat abstractions (which admittedly isn't as catchy). The problem with DRY is when abstractions with currently identical implementations are given a single interface, even though they're logically distinct. Then, when those distinct abstractions' implementations need to diverge, you've got a rats nest of references to manually pick through and separate out. Or worse yet , the mistakenly-shared interface becomes parameterized, leading to a horrible mixing of requirements and concepts that may never be untangled if the original intent is lost to time. Obviously DRY is great when you can consolidate multiple implementations that are actually a single abstraction, but it can really go off the rails if the motivation for the mantra isn't understood.
- throw1234651234 4y agoDRY is priceless, and if your argument is to avoid DRY in very specific cases, state that specifically. DRY, when used with functional, well named code is the number one thing keeping a codebase easy to read. There should be one way to achieve something well-defined like save/edit/delete an entity, check a file type, url encode a string, etc. This ALWAYS leads to much easier code fixes AND much easier refactoring.
- lolinder 4y agoYes, that happens, but I've also had to take over a large iOS app written by a self-taught programmer who never learned DRY. They didn't factor out any shared code whatsoever. Any time they needed to do something that had already been done, they just bounced over to the other controller and copied the code over. Of course, the copied code was often buggy, and they would only fix the instance in the controller where the bug was reported. When bugs were fixed it was pretty much random chance which version would be chosen to copy when needed again, so creating the right abstractions involved piecing together an entire phylogenetic tree of the code to decide which pieces were supposed to be the same and which were legitimately different. Add a commit history that looked like "v1", "v2", "v3", and... yeah. We finally decided it would be cheaper to scrap the app and rewrite it from scratch. So, yes, premature abstraction is a huge problem, but so is the opposite extreme, and after that experience I personally would choose overly-indirect code over the mess I inherited. It's easier to untangle a function that has too many callers than it is to find code that should have been shared after months of divergent evolution.
- numbsafari 4y agoWhen I was younger, I really thought this was the be all end all, and probably committed more programmatic sins due to trying to achieve DRYness than anything else. Often times it seems like we aim for DRY at the expense of simple, or idiomatic code. It also has a nasty habit of making code difficult to change since it leads to a lot of premature coupling, where someone sees a repetition and naively assumes that that needs to be eliminated, when it might literally be a naturally independent value.
- raffraffraff 4y agoIt's definitely something that people overdo. But sometimes, especially with things like terraform, you have to struggle against the DSL to avoid having thousands of lines of repetitive code to do what could done in 100. I'll go quite far to avoid the situation I saw at at previous company, where they had 36k lines of trash to run a few data centers. Deploying a new data center was next to impossible.
- bazoom42 4y agoMy take is the opposite. DRY can be overused, but it is much easier to “undry”, than it is to consolidate duplicate code which should have been dry from the beginning. Sections of duplicate code tend to drift apart over time, making it more difficult to consolidate down the road.