101–110 of 501 posts
Is it, though?
And yes, I would totally just make it so the function detects whether I am passing in an object or an array of objects and respond accordingly.
I feel like I got this pattern from jQuery or something. Seems very normal for a good library.
Ironically the author just demonstrated why DRY is a great principle.
Earlier quoted context omitted.
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…
Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…
A functional style certainly helps. I get the pizza in my hand and don’t have to worry that anyone left the oven on.
Not sure why this is on the frontpage. Not only are there a bunch of typos, a bunch of code doesn't actually work the way they said it does. Also gotta love hating on the 10x developer or whatever for saying you are wrong. EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs. Obviously you should not write terrible, brittle code. The reason DRY is important is because when you start duplicating code, having 30…
The problem is that he made his case poorly and I definitely don't agree.
> 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…
I can't agree more. Also, "code reuse" makes debugging significantly harder when trying to reverse engineer some code base. The breakpoints or printf:s get triggered by other code paths etc. And you need to traverse stack frames to get a clue what is going on.
Extra bonus points for fancy reflection so that you have no clue what is going on.
Earlier quoted context omitted.
Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…
I think that drawing conclusions from these examples is not productive at all. In the wild we're going to see functions such as def make_string_filename(s): # four lines of regex and replace magic so that we have code like file_src = make_string_filename(object_name) file_dst = make_string_filename(object_name_2) which is much more understandable than eight lines of regex magic where you don't even know what the rege…
additionally, the function should be stateless and have no side effects ;)
I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult. WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 dif…
I am sorry but that sounds like an absolute nightmare. 7 different places means 7 different times that bugs might crop up because you forgot, specially if it isn't documented that you need to copy the code in other places. It also seems a nightmare to maintain documentation about that, as comments might get lost or not updated in all the copy paste. Of course, unit tests are out of the question, are you writing 7 slightly different unit tests and keeping them updated? And I'm supposing it's simple bugs, not pervasive, hard-to-reproduce, indirect bugs that take days just to find the root cause.
> In comparison, you'll stare at DRY class for 2 hours and realize you need to refactor absolutely everything, it will break half of the codebase and diffs are insanely complicated.
Sounds like a problem of overcomplicated, bad coding and bad documentation. It's not a problem with DRY.
Earlier quoted context omitted.
I think that drawing conclusions from these examples is not productive at all. In the wild we're going to see functions such as def make_string_filename(s): # four lines of regex and replace magic so that we have code like file_src = make_string_filename(object_name) file_dst = make_string_filename(object_name_2) which is much more understandable than eight lines of regex magic where you don't even know what the rege…
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 ;)