1

Code analyzers like Sonar provide a metric called "Code duplication". This metric is useful, since it shows when code needs to be factorized.

Knowing that, what are the best pratices regarding this metric? For instance, in my projects, I ensure this metric doesn't go above 0.5% and if it does, refactors are made.

Is this how it is managed in the real world?

Are there some resources (books, websites) considered as a reference on this subject?

Improve this question

2 Answers 2

Reset to default
5

In all honesty, my experience is that there are no best practices anywhere, even in something like code duplication. There are only principles that work to guide practice, and practices that are good in some circumstances.

You don't mention whether you're working with automation code or application code: depending on the automation method and tooling, it's quite possible for automated testing projects to have a lot more duplication than application code projects due to the nature of the tasks performed.

Even in application code, circumstances arise where it's better to have duplicate or near-duplicate code than to refactor and isolate the duplication. Classic ASP websites come to mind (if only because I'm up to my eyeballs testing one where there is a LOT of dup or near dup code - and it's there for valid reasons), but I'm sure there are other examples.

In addition, it's very common "in the wild" for duplicate code to be used for a hotfix with the intention of refactoring later - but there is never time to refactor. This is obviously a long way from ideal, but I find there are usually two guiding principles in conflict in this situation: DRY (Don't repeat yourself) is conflicting with "If it ain't broke, don't fix it" - and the latter often wins because in many larger, older applications it's simply not possible to unit test to a level that allows for confident refactoring (also, in my experience, users will treat some of the application's bugs as features and actively use them - which can cause much suffering when those bugs are fixed).

Improve this answer
2
  • 2
    "my experience is that there are no best practices anywhere" - bravo! There are no best practices. There are many "practices which have proven good in some contexts, but may not be good in others". No best practices. No silver bullets. No magic numbers. We each have to decide what works well in our specific situation, at our specific point in time. allthingsquality.com/2010/04/… BTW - what's the best color?
    – Joe Strazzere
    Commented Nov 6, 2013 at 12:44
  • @JoeStrazzere - exactly. Ours is a profession where context is king. I've found that a lot of people want the guidance of best practices (and I freely admit that when you've been trained on best practices/hard guidelines it can be scary leaving that framework to make your own judgment call), but in software, that can too easily turn into a straitjacket.
    – Kate Paulk
    Commented Nov 6, 2013 at 12:50
0

Situation: "mostly same" files. Duplication is accepted for some reason.

Danger: Bug-Fixes in the original will be forgotten in the copy.

My idea was to make a diff of original & copy and store the result; regularly repeat this action and “diff the diffs” (2nd derivate). Then the candidates of Bug-Fixes can be detected. This could be automated, eg Jenkins-integration-server. This is only a idea, I have not performed it actually.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.