Design Principle: Don't Repeat Yourself

re: Design Principle: Don't Repeat Yourself

rkpatrick — Thu, 15 May 2008 18:46:45 GMT

I heard a very similar rule-of-thumb from my OO prof back in college. He worked at SGI and was just teaching as an adjunct, but I still have the phrase burned into my mind because I adhere to it to this day: "If you find yourself doing a copy/paste while you're coding, you're likely doing something wrong".

Design Principles To Live By

Steve Rowe's Blog — Thu, 15 May 2008 20:44:54 GMT

Object-oriented design and design patterns can seem complex. There are a lot of ideas and cases to consider.

re: Design Principle: Don't Repeat Yourself

Mark Sowul — Thu, 15 May 2008 22:14:33 GMT

This is my number one rule (its corollary is "don't hard-code constants").

If there's anything that will make your successor want to hang you in effigy (thanks Raymond), it's copying and pasting code.

re: Design Principle: Don't Repeat Yourself

Shane MacLaughlin — Sun, 25 May 2008 13:53:05 GMT

No doubt I'm telling Grandma how to suck eggs here but..

This reminds me very much of the traditional computer science arguments relating to cohesion and coupling. If you are tempted to cut & paste a piece of code (functionality) from somewhere, with the intention of modifying it slightly, there is a good argument for generalising the existing functionality to handle the new requirements as this will lead to less code to maintain in future. The counter argument is that by modifying the existing functionality you risk breaking systems that depend on that functionality, and require additional interfaces to that functionality. Basically, do we increase cohesion (good), or minimise coupling (good), where the two are in opposition. My OO approach is usually to add a new interface to the existing functionality, in order to minimise potential for breaking existing code, i.e. favouring strong external cohesion at the cost of some extra coupling. Where I'm adding additional parameters to support new requirements, I base it on the nearest interface, and change the body of that interface to call the new interface with default values for new parameters. This is an attempt to maximise internal cohesion.

Interestingly ( or not :) ), I'm seeing quite a bit of discussion on cyclomatic complexity at the moment on another forum, and I find that changing older and legacy interfaces to call newer interfaces as a mechanism for maximising internal cohesion also reduces cyclomatic complexity.

Really just a load of obscure technical jargon referring to the same thing, and nothing that new to experienced programmers.

Quote of the Day

Simone 'Wiz' Tellini — Mon, 04 Aug 2008 23:59:20 GMT

[...] a good programmer cultivates the virtue of laziness. (But not just any laziness: you must be aggressively, proactively lazy!) -- Chris Pine, dealing with the DRY rule