151–160 of 501 posts
Obviously YMMV.
In this case, the problem is with a bug creeping in: crust: "thyn", DRY is about avoiding this class of cut-and-paste bugs too. Or with changing a string to a token, as it should have been: crust: THIN The code isn't even correct. It's mixing JavaScript and Python. I'm also not sure why you'd declare functions for each type of pizza; that's data. I'm not sure about the context, but the right way is: def make_pizza(cr…
Being dry about state is actually really useful (essential!), where state can be derived it should be, rather than stored as a new variable. Being dry about code is often less useful in my day to day coding, but I’m not a library designer I just make apps /2c
As anything it is just a tool in our toolbelt and should be used carefully. If our system contains same user validation in 2 places, changing it in 1 place may lead to issues, which are difficult to discover. However forcefully implementing DRY everywhere can lead to coupling and lack of separation between modules and influence deployments, and work of different teams. Its more difficult to build context of the imple…
Disagree. Quicker discovering issues difficult to discover is actually a good thing.
> Its more difficult to build context of the implementation, if one needs to jump from file to file.
Agree.
In general, I personally look at DRY as "It takes time to implement and/or understand it, but when it's done then it works and it will last." "It takes time" is something your boss won't like, but that's (mostly) not an issue if working on open source SW. No boss -> no pressure -> higher quality.
Especially if there is a very common refactoring bug and you get a pepperoni pizza instead of a pizza with one of the most natural toppings like pineapple. But I tend to agree with the author. Sometimes verbosity is the lesser evil. No suggestion should become a dogma and whoever played some games of code golf knows that short code doesn't mean code that is easy to read. Extreme example of course. But I believe many…
My favorite pizza is pepperoni with pineapple and red beans.
They were awesome, but all the code examples where DRY to the max, it was quite funny.
If code is coincidentally the same, then you should leave it alone - the two pieces of code are likely to evolve independently and trying to make a common function/class handle two separate usecases is likely to lead to complex, ugly code.
Conversely, if the two pieces of code are intrinsically the same then you SHOULD pull them out into something common. If you don't, you risk the implementations drifting and getting inconsistent behaviour over time.
Determining which is which is a matter of interrogating your domain and business logic, which is the essential function of our job as developers/engineers.
Earlier quoted context omitted.
While one can certainly over-engineer everything into N levels of abstraction either with OOP stuff or with FP stuff like higher-order functions (or higher-higher-...-order functions for that matter), I could well imagine, that a person who knows FP stuff would not have as much of a problem with a specific code base and when that person leaves and only OOP-only people are left, they scratch their heads and call it an…
Honestly, I'm done trying to flip the script and approach it as a "well maybe they truly need smarter people to read the code". Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and…
I would add though, that the opposite of DRY and SOLID are feared for good reason. Just imagine, if you had duplication everywhere, because the previous developer did not understand or did not take time to introduce fitting, suitable abstractions or indirections. So these principles are definitely worth something. I guess learning to apply them in the right moments is also something, that needs practice.
Earlier quoted context omitted.
> Mistake 1: Switch from DRY to premature optimization. "Premature optimization" is largely a bogus concept, because the meaning of "optimization" has shifted a lot since the concept was first created. People now use optimization to mean "sensible design that does not needlessly waste resources". In this meaning of optimization, "premature optimization" is a bogus concept. You should absolutely ALWAYS write non-pessi…
> In this meaning of optimization, "premature optimization" is a bogus concept. The idea is that you can end up optimizing before you know the entire use-case, because software engineering isn't like building bridges or skyscrapers. I'm a performance geek, but I love code I can easily change rather than code that is fast until some customers have touched it. Mostly out of experience with PMs with selection bias on wh…
That's the whole point of my comment.
The word "optimization" as currently used confabulates two separate concepts:
- Non-pessimization (new meaning of "optimization")
- Micro-optimization (original meaning of "optimization")
You're talking about micro optimized code, and I'm talking about simple non-pessimized code.