4 ms·

I think it's pretty easy to come up with a counter argument like "hey what if I want to change the code for this one page and not the others? well, good thing e

I think it's pretty easy to come up with a counter argument like "hey what if I want to change the code for this one page and not the others? well, good thing each page has its own separate code!" If the code in question was shared, this person would have to spend time thinking about whether to add a boolean flag to the shared function, create a new function, or what-have-you. And I can see other comments here saying that boolean flags are also tech debt. For your scenario, I completely agree that the decision to not share code lead to you spending more time. We can be objective about time spent for specific scenario A with codebase B, but we cannot enumerate all scenarios and all codebases and so it's quite hard to ask what's the expected value for "damage done" by a particular style of programming.

iopq 4y ago
Boolean flag is also a design that doesn't scale to multiple decisions. You should get used to designing things in a way that separates those concerns. Why does page A need functionality in this manner and page B needs a slightly different one? It's because they do similar things, but there's a difference there somewhere. Instead of copy pasting from page A and changing it, you should have a function that does the same things from page A and B, and then combining that partial result into the different pages in the way that you want. The function that does the same task for the pages can then be fixed for both pages if it has a bug in it. If you copy/paste then inevitably the person working on it will forget to find and fix one of the versions. But even if you end up spending a little more time to prevent code duplication than just copy/pasting, it STILL yields benefits in the lower maintenance cost since people will spend less time reading and understanding the code. Your codebase will have fewer lines of actual code, which is a win by itself, which you can quantify. You won't be able to measure the time each person will waste re-reading identical code to make sure it's actually identical (or worse, trying to see WHY it's not identical), but it's always a cost if you're working with this code. The only reason not to touch it if it's already perfect and won't be changed. But usually I will start on this refactor when I do have a requirement (it already has a bug, or I need to change functionality)

iopq 4y ago

Boolean flag is also a design that doesn't scale to multiple decisions. You should get used to designing things in a way that separates those concerns. Why does page A need functionality in this manner and page B needs a slightly different one? It's because they do similar things, but there's a difference there somewhere. Instead of copy pasting from page A and changing it, you should have a function that does the same things from page A and B, and then combining that partial result into the different pages in the way that you want. The function that does the same task for the pages can then be fixed for both pages if it has a bug in it. If you copy/paste then inevitably the person working on it will forget to find and fix one of the versions. But even if you end up spending a little more time to prevent code duplication than just copy/pasting, it STILL yields benefits in the lower maintenance cost since people will spend less time reading and understanding the code. Your codebase will have fewer lines of actual code, which is a win by itself, which you can quantify. You won't be able to measure the time each person will waste re-reading identical code to make sure it's actually identical (or worse, trying to see WHY it's not identical), but it's always a cost if you're working with this code. The only reason not to touch it if it's already perfect and won't be changed. But usually I will start on this refactor when I do have a requirement (it already has a bug, or I need to change functionality)