This is a good article, I'm sure I'll find myself saying "no bad bunny code" soon.
I've encountered this phenomenon and there are a few situations where it can feel natural or correct to copy and paste code. While I can't say these are great reasons, they do merit being considered.
0. QA concerns. You can't just modify/change logic without triggering a need for QA to re-check. This is in fact, one of the biggest stumbling blocks for code quality in a company. You just can't refactor as needed, it has to be planned for and paid for. There are times when you're basically stuck using bad/logic and just extending it.
1. You're a guest in the code. You're just working on this feature for one iteration, and the other guy who will likely be on the project for the rest of the year wrote the bunny code. I wouldn't change how he does things, I'd instead talk him and let him know there's a better way. I wouldn't implement a second type of fix.
2. It's unclear what direction the primary authors want the codebase to grow in. For instance do you use library level functions to accomplish tasks the language syntax can? (for loops vs an iterator function). Some prefer one over the other. I would just follow the style I see
3. Styleguide logic. E.g. the code should look as much as possible like it's written by one person. While I know this rule applies to indentation and visual appearance. I think it's fair-ish to apply to it to logic as well.
These are a few things to think of, but I agree with the author of the post, be careful, this code will multiply.
I've encountered this phenomenon and there are a few situations where it can feel natural or correct to copy and paste code. While I can't say these are great reasons, they do merit being considered.
0. QA concerns. You can't just modify/change logic without triggering a need for QA to re-check. This is in fact, one of the biggest stumbling blocks for code quality in a company. You just can't refactor as needed, it has to be planned for and paid for. There are times when you're basically stuck using bad/logic and just extending it.
1. You're a guest in the code. You're just working on this feature for one iteration, and the other guy who will likely be on the project for the rest of the year wrote the bunny code. I wouldn't change how he does things, I'd instead talk him and let him know there's a better way. I wouldn't implement a second type of fix.
2. It's unclear what direction the primary authors want the codebase to grow in. For instance do you use library level functions to accomplish tasks the language syntax can? (for loops vs an iterator function). Some prefer one over the other. I would just follow the style I see
3. Styleguide logic. E.g. the code should look as much as possible like it's written by one person. While I know this rule applies to indentation and visual appearance. I think it's fair-ish to apply to it to logic as well.
These are a few things to think of, but I agree with the author of the post, be careful, this code will multiply.