No, the correct way is, write down some configuration, then with a little code to turn config into real pizza !
DRY is an over-rated programming principle?
11–20 of 501 posts
Re: DRY is an over-rated programming principle?
#12left_toppings = ["beef"] right_toppings = [] make_pizza([left_toppings, right_toppings]) # this will be a very funny pizza Holy cow I was not expecting a none pizza with left beef reference in code form
For those wondering, it's a reference to this beauty: https://i.kym-cdn.com/photos/images/facebook/000/838/967/e39...
Re: DRY is an over-rated programming principle?
#13> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high.
Mistake 1: Switch from DRY to premature optimization.
> You might think that legit reasonable developers but would not actually do something like this and would instead go back to the existing invocations and modify them to get a nice solution, but I've seen this happen all over the place.
Mistake 2: Assumption of incompetence to support your argument.
> . As soon as we start the thought process of thinking how to avoid a copy paste and refactor instead, we are losing the complexity battle.
Mistake 3: Strawman argument. DRY does NOT lead to over-complicating things. Overcomplicating things leads to overcomplicating things.
Now, i wasted 5 minutes, so you can waste some more to reply to this comment, instead of completely ignoring this dumb random blog post.
Re: DRY is an over-rated programming principle?
#14DRY is better for performance (cache efficiency). It’s also less work for the compiler. Those might not be concerns of someone writing pizza CRUD in python.
Re: DRY is an over-rated programming principle?
#15The DRY example is better though. The payload is an object. When you have multiple objects of the same shape you have a class of objects. Menu items could be loaded from a JSON source. Separation of concerns and duplication is removed from the code.
Re: DRY is an over-rated programming principle?
#16I disagree with the author's example as given.
The example discusses a code boundary that is internal to a single atomic "module" - the preparation of a data structure that describes a pizza. Then the author says that bad things will happen if said code boundary is used from other modules.
However, why would an extrenal module developer do that? It is common wisdom to recognize and avoid module-internal utility functions.
Conversely, as long as the presented shortcut is internal to a module (=used only for a specific set of use cases well understood by anyone touching the code), and saves toil, it might actually be justified.
Re: DRY is an over-rated programming principle?
#17Personal anecdata. I have been increasingly aware of my own mental patterns during development and I've noticed that often I've been sitting and mulling over refactoring to some sort of universal solution instead of getting on with the work and getting things done. There are instances when I could've finished the task twice as fast if I would've just went ahead and done it with repeating code instead of thinking of clever ways to DRY it.
Therefore for my personal projects I'm now firm believer of quick iterative building. Just get the first iteration done, get it working and save improvements for later. It may create a bit more work for the future me but it decreases the mental load quite significantly. I'll take less mental load with clear objective (refactor this because this) over more mental load with unclear objectives (make universal solutions taking into account things that may or may not happen in the future) any day.
Re: DRY is an over-rated programming principle?
#18> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high. Mistake 1: Switch from DRY to premature optimization. > You might think that legit reasonable developers but would not act…
I don't read coding opinion articles like OP but I like to check out comments.
> DRY does NOT lead to over-complicating things.
That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's used, not just in situations where it's used in a complicated way.
This sounds dumb but it just simply is much harder to keep context about what's going on around if you can't refer back to it because it's on the same screen or one short mouse scroll above or below your current screen.
That obviously doesn't mean you should leave copy pasted versions of the same code over your code base. But it's important to consider that refactorization of that code into something common that gets called from multiple places as something that you don't get for free, but that is an active trade off which you usually have to apply to prevent bugs (changing one code location and not the other) or simple code bloat. In practice this is very relevant when you suspect something might be repeated in the future, but you're not sure. Imo: Just don't factor it out into anything, leave it there, in place, in the code.
Re: DRY is an over-rated programming principle?
#19I disagree with the author's example as given. The example discusses a code boundary that is internal to a single atomic "module" - the preparation of a data structure that describes a pizza. Then the author says that bad things will happen if said code boundary is used from other modules. However, why would an extrenal module developer do that? It is common wisdom to recognize and avoid module-internal utility funct…
> However, why would an extrenal user do that? Potential external users typically recognize and avoid module-internal utility functions.
External users will go look the implementation of msvc's standard library and reverse engineer windows API to make things faster lol. No internal module function is ever safe.
Re: DRY is an over-rated programming principle?
#20There's no silver bullet. My opinion is that you should weight alternatives without repetition and with repetition and choose the most appropriate one. Also if in the future you feel that this common code is becoming more complex with options and switches, feel free to remove it by inlining, either completely or in a few places. Often it'll allow for better code or it'll allow to find out another way to extract common code.
Basically I like the refactoring approach. You have a set of refactorings. Like extract method / inline method. The point is that every refactoring is two-way. And both ways are useful in different situations.
To support this approach, sane IDE is a must and strictly typed language is preferable You should refactor your code without fear of breaking unrelated code.
What I definitely think is overrated is "if it works - don't touch it" principle. It's lazy and in the end it creates much more work than if one would gradually improve something that works.