Isn’t the only reason we care about duplicate code that we don’t want to miss an instance of it for enhancements or bug fixes down the line? Don’t we have technology that helps us reduce that concern?
Goodbye, Clean Code
31–40 of 599 posts
Re: Goodbye, Clean Code
#32I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
[deleted]
Re: Goodbye, Clean Code
#33> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. If you want to modify a method that has 10 unique contributors. Do you really need to talk to different 10 people to maintain to make a change? That does not sound very effective. And, most importantly: when you code as a job, all your deliverables are company's property. They are not yours. The company can…
> If you want to modify a method that has 10 unique contributors. Do you really need to talk to different 10 people to maintain to make a change?
I think the more apt example in this case would be if somebody made a modification in that file and you rewrote just their modification immediately after they done it without discussion. If the modification is necessary so soon it means that the feature/implementation were not discussed properly before and the process probably needs revisiting.
Of course if you are modifying part of the file, or doing some previously agreed refactoring effort then explicit author consent is not necessary.
> Secondly: version control. If you want the old version of some code
I think here we talk mostly about production code. The problem with relying on the source control for "I will revert this to the old version when it will become required" is that the code will evolve in subtle manners and it will be hard to roll back and apply all patches on top of it.
Re: Goodbye, Clean Code
#34Off topic:
Docusaurus V2 makes a really clean looking blog via GitHub pages. Cheers
Re: Goodbye, Clean Code
#35Earlier quoted context omitted.
A good post about someone learning that writing code is more than just about how pretty it looks. How you work with others is incredibly important in this industry
Is that not common knowledge? I feel like this is a well-written post with a good point but it's a familiar point. You could boil part of it down to 'all's good in moderation', so don't just keep your code clean, keep it clean and easy to read, etc.
Leaving common knowledge undocumented is, in itself, a misguided attempt at DRY.
Your common knowledge isn't necessarily everyone's common knowledge; what you perceive isn't necessarily what it is.
Every day there are many people just starting to code. There are cultural and regional differences. They might not have hit the exact spot in which this information appears.
Knowledge also disappears, fades, gets censored or destroyed, gets mixed up and remembered incorrectly. You might take something as a given and misremember it 20 years from now. You might read your own code 5 years from now and not know why something's there — something that was taken to be obvious.
Re: Goodbye, Clean Code
#36Re: Goodbye, Clean Code
#37I think this highlights an important nuance to the Don't Repeat Yourself maxim. It's not just about whether two bits of code are similar now. It's about whether, when they change in future, they are likely to change in the same ways. If not, then DRYing up the code now is only making more work for yourself down the line.
I've always found the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle , where you derive from classes instead of editing them in-place, sort of appealing for this reason.
What is this implying? That instead of adding a property/method to a class you should instead create a child class that inherits from the original with the new properties? Sounds like a great way to have a very complicated class hierarchy IMO
Re: Goodbye, Clean Code
#38I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…
> Then you need to start passing options and configuration into your helper method... and before long your helper method is extremely difficult to reason about
In which case, you should split the helper function ( extract sub-part common to all cases, and report the differences where the helper function is called).
I think I would most of the time go with de-duplicating as early as possible, as long as the helper function only has few parameters and can be described in plain english rather easily.
To me the cost of having to refactor the helper function later in the process is less than dealing with duplicated code.
Duplicated code causes many issues. You mentioned introducing bugs, but it also makes the code harder to read. Every person who reads the code has to make the de-duplication effort mentally (check that the duplicated parts are indeed duplicated, figure out what they do, and on what parameters they differ...).
Re: Goodbye, Clean Code
#39Clean code and Agile is excellent and is important to use in enterprise applications. The author needs to educate himself
Re: Goodbye, Clean Code
#40Earlier quoted context omitted.
I've always found the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle , where you derive from classes instead of editing them in-place, sort of appealing for this reason.
What is this implying? That instead of adding a property/method to a class you should instead create a child class that inherits from the original with the new properties? Sounds like a great way to have a very complicated class hierarchy IMO
Exactly that. Just because you want new behavior doesn't mean all the other consumers of that class also want it. The old behavior should still exist, and have a name. I'm not sure whether the idea was ever fully developed into patterns for replacing deep hierarchies with simplified classes that factor out some inheritance from otherwise-unused base classes.