Vignette: How to sensibly use {dupree} as part of your workflow

[russHyde]

DON'T JUST DEDUPLICATE WITHOUT THINKING!

Write up a vignette of a sensible workflow:

The aim is to add useful functionality that reduces the floor-space for bugs without deduplicating so far that your code becomes unreadable

Two main approaches:

• If you want to fix a bug
  • Write a test that traps the bug, if you can
  • Isolate the code that is affected by the bug
  • run dupree and see if that code is duplicated elsewhere in the package
  • [see if you need to write a test that captures bugs in the duplicated bits]
  • [deduplicate the duplicated bits of code & then fix the bug]
  • OR [fix the bug(s) and then deduplicate]
• If you want to add a feature
  • again, write tests for the new feature
  • write the code to implement your feature
  • run dupree; find if your feature-code duplicates some other part of the package
  • refactor the duplicated bits of code

As such, {dupree} doesn't really fit into the goodpractice-type checks (where you analyse the current state of the whole package relative to general guidelines); you need to consider before & after and focus on the bit of code that you are currently modifying. [? does that make sense]