The thing with DRY code is, you need to look at your abstractions from further away than just the code level.
If a chunk of code does a very well defined thing, something that's a reasonable action within the problem domain? Then it should be abstracted into some form of construct (be that a class, function, whatever). Think of methods like cancelling an order; this will likely happen at more than one place and is a distinct process even if you set aside the code.
Something like a popup is a bit tricky; when the code is well written, there's nothing inherently wrong with a single modal class that takes a bunch of callbacks and has a bunch of different variants. In OOP these would normally be separated out into subclasses, but in languages like C it's also not that strange to simply use flags for such behaviour.
The problem really starts when the code structure is bad and the class turns into an entangled mess.
Generally speaking, DRY code is better than WET code (which I prefer to read as "We Enjoy Typing"), because copy-paste errors are a very real threat and keeping two different sections of code in sync is another pitfall that may introduce bugs when one of these sections is forgotten.
Another problem that often gets overlooked with DRY code is that some times two sections of code just happen to follow the same logic, but don't really relate to each other in any way. Abstracting this common code out into a separate construct might turn out to be a terrible mistake if one of these sections ends up changing while the other doesn't: now you have to roll the abstraction back or bloat your abstraction.
Always be aware of which code is shared incidentally and which code share reflects actual shared domain logic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The thing with DRY code is, you need to look at your abstractions from further away than just the code level.
If a chunk of code does a very well defined thing, something that's a reasonable action within the problem domain? Then it should be abstracted into some form of construct (be that a class, function, whatever). Think of methods like cancelling an order; this will likely happen at more than one place and is a distinct process even if you set aside the code.
Something like a popup is a bit tricky; when the code is well written, there's nothing inherently wrong with a single modal class that takes a bunch of callbacks and has a bunch of different variants. In OOP these would normally be separated out into subclasses, but in languages like C it's also not that strange to simply use flags for such behaviour.
The problem really starts when the code structure is bad and the class turns into an entangled mess.
Generally speaking, DRY code is better than WET code (which I prefer to read as "We Enjoy Typing"), because copy-paste errors are a very real threat and keeping two different sections of code in sync is another pitfall that may introduce bugs when one of these sections is forgotten.
Another problem that often gets overlooked with DRY code is that some times two sections of code just happen to follow the same logic, but don't really relate to each other in any way. Abstracting this common code out into a separate construct might turn out to be a terrible mistake if one of these sections ends up changing while the other doesn't: now you have to roll the abstraction back or bloat your abstraction.
Always be aware of which code is shared incidentally and which code share reflects actual shared domain logic.