DRY is mostly a good thing. What complicates stuff at companies is often coupling and dependencies though. Sometimes it is way faster and better to do a bit of copying just for the sake of removing coupling. This is largely due to the short comings of programming langs, packaging tools, CI/CD and source control.
DRY is an over-rated programming principle?
261–270 of 501 posts
Re: DRY is an over-rated programming principle?
#262I tend to start DRYing up my code after five usages. I think it's a balance that has kept me away from the unnecessary complexity, although the Gateway drug is real- I catch myself wanting to DRY early now and then
Re: DRY is an over-rated programming principle?
#263When I hear “DRY”, I think of Django with its Models, ModelForms, etc., not enterprise Java where every piece of functionality is hidden behind 15 levels of indirection.
Re: DRY is an over-rated programming principle?
#264Earlier quoted context omitted.
If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase. Not sure if this is always feasible. Add DB to that and this means that you have to always check for constraints at DB level.
You could consider codegen from the single point of truth. Not always practical, but great when its set up with good ergonomics.
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?
Re: DRY is an over-rated programming principle?
#265If I can be a little too honest here, I will admit that I just don't like making programs that are too simple. I can make an extremely simple program... But it doesn't feel good. I know there will be limitations to that simplicity, and I want to make functions that do things, and combine those functions, and let them override things, and pass state, transform state, etc. Making it complex just feels better.
I actually stand outside my body and watch myself make it more complex, and think, "Ugh, this is more complex than it needs to be, I should make this simpler. But I don't want to." I continue and hope that a refactor will make it less embarrassingly complicated.
Re: DRY is an over-rated programming principle?
#266Earlier quoted context omitted.
if those 8 lines of regex have been unit tested and the function is commented to describe "what" the code does, it is entirely the point that you don't need to understand how it works additionally, the function should be stateless and have no side effects ;)
How do you test 8 lines of regex inside a function that does more things? And what's easier, to write and read the function name or copy-paste the lines with the comment (if the comment explaining what that piece does is even written, that is)?
i'm a bit confused, do we need to know the nitty gritty details of how Math.random() is written, or that it will reliably give us a random double?
Re: DRY is an over-rated programming principle?
#267This article is fine, though the headline is misleading. In the end, the author still seems to believe that DRY should be the rule, not the exception, and I agree with that.
Re: DRY is an over-rated programming principle?
#268What about something like this (in JS)?
// Option 1
const Pizzas = {
Hawaiian: {
type: 'hawaiian',
crust: 'thin',
sauce: 'tomato',
cheese: 'regular',
toppings: ['ham', 'pineapple'],
},
Pepperoni: {
type: 'pepperoni',
crust: 'thin',
sauce: 'tomato',
cheese: 'regular',
toppings: ['pepperoni'],
},
};
// Option 2
// Pizzas could be returned from an API, so that the pizza
types are configurable outside of the code
const response = [
{
type: 'hawaiian',
crust: 'thin',
sauce: 'tomato',
cheese: 'regular',
toppings: ['ham', 'pineapple'],
},
{
type: 'pepperoni',
crust: 'thin',
sauce: 'tomato',
cheese: 'regular',
toppings: ['pepperoni'],
},
];
const makePizza = (pizza) => requests.post(PIZZA_URL, pizza);
// Then, for Option 1
makePizza(Pizzas.Hawaiian);
makePizza(Pizzas.Pepperoni);
// Or, for Option 2 (e.g. user selected via a menu)
makePizza(selectedPizza);Re: DRY is an over-rated programming principle?
#269Every 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…
> 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…
This is what I call "preloopsarian": a state of coding innocence in which one has discovered assignment and alternation, but not iteration.
Re: DRY is an over-rated programming principle?
#270I like DRY. Do Repeat Yourself. You can always refactor later, once the requirement/change is fully implemented.
Repeating yourself 3 or 4 times is okay. After that, it is probably worth cleaning up.