3 ms·
It can go either way. If you duplicate code, but the two copies need to stay in sync, then you've made it a bit harder and more error-prone to maintain. But the
by smilliken 3y ago
It can go either way. If you duplicate code, but the two copies need to stay in sync, then you've made it a bit harder and more error-prone to maintain. But the worse offense is if you have some code that serves two conflicting sets of requirements, but you keep the code together with increasing complexity to thread the needle of satisfying all the requirements.
The latter is the worse offense because it's much harder to decouple two systems than it is to notice a similarity in two bits of code and to extract the commonality.
- nine_k 3y agoExactly. If you have to care about this for any prolonged time, do yourself a favor and structure your code carefully, think about the right abstractions, etc. If you only need to release it before Christmas no matter what, and sales will wane anyway in 6 months, then even worse crimes against maintainability may find a justification. The problem is, of course, is that even code that was intended as throwaway tends to live much much longer than expected, if it actually works.
- SoftTalker 3y agoYep years ago I worked on a web application that was made with "classic" Active Server Pages. Each page was a self-contained .asp file. To make a new page, you copied another page and changed it around. This meant that when you wanted to change something on all pages, it was a PITA but not always terrible because tools like grep, sed and awk exist for Windows also. The nice thing was, you could make a change on any page and know that it would only affect that page and had no (or very little) chance to introduce bugs anywhere else in the system. I wouldn't recommend the approach, but it wasn't all bad.