4 ms·

The idea of 'don't repeat yourself' is an ok guideline unless, like most proverbs/sayings/mottos/slogans it gets used as a absolute rule. feel free to ignore i

The idea of 'don't repeat yourself' is an ok guideline unless, like most proverbs/sayings/mottos/slogans it gets used as a absolute rule. feel free to ignore it, mock it and toss it aside if it leads to bad abstractions, highly convoluted structures or write-only code. anyone that has had to do maintenance or adding features to a large OO codebase from the early 2000s will have seen vastly massive class hierarchies where following the path of execution is a roller coaster ride through 10 files for what could have been a 30 line function. these days grep/vim/sublime/emacs/and the rest of the gang all have power search and replace editing functions. sometimes it's better for the whole world to just copy-paste-alter your code.

stcredzero 10y ago
an ok guideline unless, like most proverbs/sayings/mottos/slogans it gets used as a absolute rule. Amen! a roller coaster ride through 10 files for what could have been a 30 line function. sometimes it's better for the whole world to just copy-paste-alter your code. Then what happens when you have almost a hundred copy/pasted slightly rewritten 15-30 line variations on the same theme? How do you refactor then? (Yes, I have seen this is production systems, and yes, it was very critical code!) As you say, it comes down to cost/benefit. Basically, you just have to keep potential refactoring/rewrite costs down so that you are never trapped. Caveat: You can seldom predict the risks as well as you think you can. What you can depend on, is being observant to historical patterns in your codebase. It's hard to predict the business needs and the architecture in the future. On the other hand, it's often quite easy to see the historical trends in the codebase. Really, the analogy of the physical file room is a great one. (Or if you're not familiar, a library, a tool chest, or any kind of physical inventory system works too.) You can have a file clerk that seems like "super-filer" because he never "wastes" time by putting files back, but this never works out in the long term. The same goes for a filing staff that never reorganizes the file room. Also, one can generally see the long term disaster developing long before it results in the dramatic disaster. You can see which shelves are getting filled up, and which drawers are getting overstuffed, usually weeks or months ahead of time.
- Asooka 10y ago
  > Then what happens when you have almost a hundred copy/pasted slightly rewritten 15-30 line variations on the same theme? How do you refactor then? (Yes, I have seen this is production systems, and yes, it was very critical code!) As you say, it comes down to cost/benefit. The only thing that can happen - you understand the core function those 30 variations solve and introduce a full parametrised solution to the problem, then replace all places with calls to it. Generally there would be some way to tell where all these copy-pastes are using something not much more complex than a regex. But even then, maybe just leaving it duplicated is better.
  - Bjartr 10y ago
    The concern I have with this approach is how easy it is forget to alter one of the variants when you alter one of them. How do you know the code you're touching has other versions that are semantically the same and should also be altered?[1] How do you avoid having to fix the same bug several times because you bug-fixed one place but not the others? How do you avoid the technical debt that builds over time when instances of the pattern within the codebase are each at subtly different "versions" with similar, but not identical, semantics (even though identical would have worked fine?) [1] Of course, DRY code has the inverse: How do you know if an existing function to do what you want to do already exists so you can avoid duplicating the extraction? Where my opinion falls today is: A slightly more complex solution is often less risky and more maintainable than the straightforward duplication solution because at least the complex one looks complex to a would-be maintainer who will at least be aware of things up front, whereas duplicated code can have a bunch of hidden costs whenever it's touched that won't necessarily become apparent until later when the presence of that technical debt throws a monkey wrench into unrelated plans.
    - rocqua 10y ago
      If your variants need to be similar, that alone is a great reason to abstract. It makes the abstraction more valuable. Meanwhile, there could easily be transformative code that just computes some stuff you often need. In those cases altering one variant need not effect the others.
hinkley 10y ago
I've had a particularly bizarre experience a few times recently. At a previous company we had identified that we needed some bit of code to solve a critical business problem, we tackled it, solved it fully, on the second or third try, and put it into a library function that underpinned the whole app. We did such a good job that we never touched it again. My next company or a place I interviewed could just not understand why I couldn't answer questions about something so fundamental to our success. Certainly I must be overplaying my involvement in the project. The joke I make is that we spend all of our time looking at the trivial code in our apps. The more important it is the less time we spend touching it, which is just so backward from other industries and I don't know how we fix it.
dllthomas 10y ago
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" It's a much better rule as originally stated than as misapplied. That's not to say that there won't be exceptions, even to the original rule.
userbinator 10y ago
these days grep/vim/sublime/emacs/and the rest of the gang all have power search and replace editing functions. sometimes it's better for the whole world to just copy-paste-alter your code. The compiler is also quite helpful. Need to change a class? Just change it and recompile. All the places it complains about are exactly all the places that need to be changed, and a targeted search+replace will get them all easily.

stcredzero 10y ago

an ok guideline unless, like most proverbs/sayings/mottos/slogans it gets used as a absolute rule. Amen! a roller coaster ride through 10 files for what could have been a 30 line function. sometimes it's better for the whole world to just copy-paste-alter your code. Then what happens when you have almost a hundred copy/pasted slightly rewritten 15-30 line variations on the same theme? How do you refactor then? (Yes, I have seen this is production systems, and yes, it was very critical code!) As you say, it comes down to cost/benefit. Basically, you just have to keep potential refactoring/rewrite costs down so that you are never trapped. Caveat: You can seldom predict the risks as well as you think you can. What you can depend on, is being observant to historical patterns in your codebase. It's hard to predict the business needs and the architecture in the future. On the other hand, it's often quite easy to see the historical trends in the codebase. Really, the analogy of the physical file room is a great one. (Or if you're not familiar, a library, a tool chest, or any kind of physical inventory system works too.) You can have a file clerk that seems like "super-filer" because he never "wastes" time by putting files back, but this never works out in the long term. The same goes for a filing staff that never reorganizes the file room. Also, one can generally see the long term disaster developing long before it results in the dramatic disaster. You can see which shelves are getting filled up, and which drawers are getting overstuffed, usually weeks or months ahead of time.

Asooka 10y ago
> Then what happens when you have almost a hundred copy/pasted slightly rewritten 15-30 line variations on the same theme? How do you refactor then? (Yes, I have seen this is production systems, and yes, it was very critical code!) As you say, it comes down to cost/benefit. The only thing that can happen - you understand the core function those 30 variations solve and introduce a full parametrised solution to the problem, then replace all places with calls to it. Generally there would be some way to tell where all these copy-pastes are using something not much more complex than a regex. But even then, maybe just leaving it duplicated is better.
- Bjartr 10y ago
  The concern I have with this approach is how easy it is forget to alter one of the variants when you alter one of them. How do you know the code you're touching has other versions that are semantically the same and should also be altered?[1] How do you avoid having to fix the same bug several times because you bug-fixed one place but not the others? How do you avoid the technical debt that builds over time when instances of the pattern within the codebase are each at subtly different "versions" with similar, but not identical, semantics (even though identical would have worked fine?) [1] Of course, DRY code has the inverse: How do you know if an existing function to do what you want to do already exists so you can avoid duplicating the extraction? Where my opinion falls today is: A slightly more complex solution is often less risky and more maintainable than the straightforward duplication solution because at least the complex one looks complex to a would-be maintainer who will at least be aware of things up front, whereas duplicated code can have a bunch of hidden costs whenever it's touched that won't necessarily become apparent until later when the presence of that technical debt throws a monkey wrench into unrelated plans.
  - rocqua 10y ago
    If your variants need to be similar, that alone is a great reason to abstract. It makes the abstraction more valuable. Meanwhile, there could easily be transformative code that just computes some stuff you often need. In those cases altering one variant need not effect the others.

hinkley 10y ago

I've had a particularly bizarre experience a few times recently. At a previous company we had identified that we needed some bit of code to solve a critical business problem, we tackled it, solved it fully, on the second or third try, and put it into a library function that underpinned the whole app. We did such a good job that we never touched it again. My next company or a place I interviewed could just not understand why I couldn't answer questions about something so fundamental to our success. Certainly I must be overplaying my involvement in the project. The joke I make is that we spend all of our time looking at the trivial code in our apps. The more important it is the less time we spend touching it, which is just so backward from other industries and I don't know how we fix it.

dllthomas 10y ago

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" It's a much better rule as originally stated than as misapplied. That's not to say that there won't be exceptions, even to the original rule.

userbinator 10y ago

these days grep/vim/sublime/emacs/and the rest of the gang all have power search and replace editing functions. sometimes it's better for the whole world to just copy-paste-alter your code. The compiler is also quite helpful. Need to change a class? Just change it and recompile. All the places it complains about are exactly all the places that need to be changed, and a targeted search+replace will get them all easily.