I wholeheartedly agree with the author where he talks about documentation. Documentation is presentation, and you present to different audiences. You will repeat concepts.<p>However, duplicate code is the greatest sin in software design. Almost every good practice or rule we have conjured is an attempt to reduce code duplication. Redemption comes in the form of abstraction. How could anyone defend duplicate code?<p>The author mentioned two kinds of duplication in tests. The first is a case of "You're doing it wrong." Here is a good rule of thumb for tests: if you find yourself copy-pasting between the code you wrote and the test you write for that code, you are not testing the code. Find an alternative way to test it. You will find a lot more value in it.<p>The second is a discussion of setup and teardown being repeated. You are writing a lot of extra noise. Perl's Test::Class, for example, allows you to write <i>one</i> setup and teardown for all the tests in a Test::Class child. Reduce copy-paste by grouping together classes of tests. Even without a nice test framework, setup and teardown are trivial to implement yourself. Don't write tests that are a series of lines in one large main function.<p><i>Sometimes you can factor out this duplication. However, in less dynamic languages like C, it may not always be easy to do so.</i><p>What does this "less dynamic" mean? The example is easy to refactor into a function for both:<p><pre><code> stuff(1);
call_something_unrelated();
stuff(2);
</code></pre>
C can abstract. It is not as good at abstracting as Lisp (what language is?), but there are solutions for most situations.<p>Don't ever accept the idea that code duplication is legitimate.
DRY when it makes things simpler. Sometimes you would have to make things so much more complicated in order to completely not repeat yourself that it ends up not being worth it if it's not maintainable or difficult to debug what it's doing.<p>The point of DRY is to keep things simple and more maintainable. If DRY ends up making things more complicated and less maintainable overall then hold your nose and use your judgment. DRY makes some people miss the forest for the trees; KISS is better than DRY, which ought to be subservient to it.
I completely agree. I think DRY is a very single-developer orientated aspect. There is value in repeating your self or copy and paste programming as that can enable further polish and customizing where DRY causes more intense mental activity to keep everything clean.<p>Inspired new blog article: <a href="http://blog.mathgladiator.com/2010/11/avoid-dry-for-product-development.html" rel="nofollow">http://blog.mathgladiator.com/2010/11/avoid-dry-for-product-...</a>