A little copying is better than a little dependency - Rob Pike
DRY code is a good value, but it is not an all important value. It's one of many values, and must be kept in balance.
DRY is an over-rated programming principle?
431–440 of 501 posts
Re: DRY is an over-rated programming principle?
#432A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t jus…
This is much better although I'd argue even it can be taken too far.
Any rule in engineering "can be taken too far" in the sense that there are times when other considerations will win. SPOT (which actually seems equivalent to the intent of DRY, although I recognize that that use might not be well represented in the memepool) is something that is probably always a win on its own terms, but in some cases introduces other costs that exceed the actual benefit. I think that's meaningfully different than the overly syntactic (mis?)interpretation of DRY, where it's true that things looking similar might hint that there's something to factor out, but sometimes factoring that thing out is a bad idea simply because it is actually two separate "pieces of knowledge" that just happen to be the same at the moment.
Re: DRY is an over-rated programming principle?
#433A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t jus…
Occasionally, it's not clear if a single point of truth is entirely appropriate, or even if it is it can lead to tiresome extra levels of abstraction. In this case, I sometimes prefer a slightly different approach; let's call it CRAP - Cross Reference Against Protocol: instead of definitions effectively referring physically to the same point of truth, they are designed instead such that they simply cross reference ag…
> Occasionally, it's not clear if a single point of truth is entirely appropriate
Feels similar to the monolith/microservice discussion in that it's mostly context sensitive. I think the term "programming principle" is misleading, these are tools with specific applications.
Re: DRY is an over-rated programming principle?
#434Earlier quoted context omitted.
On a similar note, tree/graph structures should be avoided versus lists unless there is a good reason. Flat is better than nested. A linear block of code is far easier to reason about than a network of function calls, or (heaven forbid) a class hierarchy. Not that such tools don't have their place, but I've seen too much convoluted code that has broken simple things into little interconnected bits for no reason other…
I'm not sure I follow... Can you provide an example? (junior dev here) If I understand some of it correctly, I was contemplating this when I started writing functions for "single functional concepts" like, "check for X; return true or false", then called each of those functions sequentially in a single "run" function. Is that what you mean? I found that approach much easier to test the functions and catch bugs, but y…
Specifics might depend on the language, domain, and team (and individual preference), so it's hard to avoid being general.
I would say some junior devs can get too fixated on hierarchies and patterns and potential areas of code re-use, though; instead, they should try to write code that addresses core problems, and worry about creating more correct abstractions later. Just like premature optimization is the "root of all evil", the same goes for premature refactoring. This is the rule of YAGNI: You Ain't Gonna Need It. Don't write code for problems you think you might have at some indeterminate point in the future.
When it comes to testing, TDD adherents will disagree, but if you ask me it's overkill to test small private subroutines (or even going so far as to test individual lines of code). For example, if I have a hashing class, I'm just going to feed the hash's test vector into the class and call it done. I'm not going to split some bit of bit-shift rotation code off into a separate method and test only that; if there's a bug in that part, I'll find it fast enough without needing to give it its own unit test. That's what debuggers are for. All the unit test should tell me is whether I can be confident that the hashing part of my code is working and won't be the cause of any bugs up the line.
Obviously I'm not in the "tests first" camp; instead I write tests once a class is complete enough to have a clearly defined responsibility and I can test that those responsibilities are being fulfilled correctly.
Re: DRY is an over-rated programming principle?
#435Earlier quoted context omitted.
Where is the typo? And the usefulness of your comment?
the typo is "non-pessimized code", which should be "non-optimized code". I see humor in thinking if my code is pessimistic enough. Have I assumed that the edge cases will happen and worked around them? Do I expect (and handle) crashes, i/o failures, network timeouts, etc? "code pessimism" could be an interesting metric. The typo in the other post was "superb owl" which should have been "super bowl". Several people on…
It's a term of art used by Herb Sutter, among others: https://stackoverflow.com/q/15875252
Re: DRY is an over-rated programming principle?
#436Every time I read an article like this, "why is overrated", I think, yeah you are right in theory. But most places I have worked, these best practices were not overused, but underused. If you have the problem that your coworkers create unneccessary abstractions, I envy you, because I have so often had the opposite problem. Maybe this is not the case if you work in a great software development team. But if you work so…
In places I've worked DRY is overused, or used poorly. I can't count the number of times you get "DRY" on a code review just cause something appears twice. It's probably because it's the easiest one to spot. > learning the acronyms like DRY, and just following them Following DRY is the hard part. As the author points out, to DRY something up you need to pick the right level of abstraction. This requires experience to…
It seems like your team should check for DRYness with a static analyzer like PMD. Your reviewers have better things to look at.
Re: DRY is an over-rated programming principle?
#437A better formulation of DRY is SPOT (Single Point Of Truth). Definitions (code, data) that represent the same “truth”, i.e. when one changes all have to change to represent a consistent truth, should be reduced to a single definition. For example, if there is a rule that pizzas need at least one topping, there should only be a single place where that condition is expressed, so that when the rule changes, it isn’t jus…
I agree with this as it puts emphasis on semantics rather than syntax and encourages focusing on intentionally similar code rather than unintentional. A related principle is what I call code locality. Instruction locality is the grouping of related instructons so they can be the CPU's cache (can an inner loop fit all in cache). Similar for data locality. Code locality is for humans to discover and remember related co…
I like your terminology of code locality. Personally, I've always thought of it as being the "ctrl+f" principle. If I'm reviewing a PR or looking at the source in GitHub, it's a lot easier if I can find definitions via "ctrl+f" without resorting to an IDE. Sure, it's probably best practice to checkout code changes I'm reviewing and open them in an IDE, but that often isn't what happens in practice and if I'm reading third party code, configuring the IDE to understand the project might take a lot of effort. The stronger rule is that it should not be necessary to use a stronger tool than a project wide find to lookup references to some function/data structure.
Re: DRY is an over-rated programming principle?
#438Earlier quoted context omitted.
Codegen is great for lots of sync between client and server (I just wish there were more standardized tools), but what if it's a complex algorithm that you need to be able to perform both client and server side, assuming they use different languages?
You've answered one of the easiest ways to do it: just use the same language. Node (and Deno/Bun) is a good way to maximize code sharing and single points of truth. But I definitely understand not everyone wants to write all of their backend in JS (or even TS). (Node ORMs sometimes don't have the polish of their cousins in other languages, for instance.) There are great opportunities here for language mixing, however…
You're assuming a web client. The example I had in mind was a mobile client, where we actually used a cross compiler to generate java byte code from swift to allow code sharing between iOS/Android clients, but that wasn't usable for the backends (which were C# mostly). Which is why I went with a server-precomputed lookup table in the cases the number of possible inputs made that feasible. If not, reg-exes for validation (with tooling to enable sharing between codebases) are a decent alternative in many cases. But I was curious what other options HN readers might have tried.
Re: DRY is an over-rated programming principle?
#439I think Kent C. Dodds gets to the goal behind the DRY principle fairly well here:
Re: DRY is an over-rated programming principle?
#440Earlier quoted context omitted.
> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…
I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.
I've seen this in Ruby and Elixir that drives me a little nuts:
if !is_nil(foo)