There is really one overriding principle that I violated when things become messy: Separation of Concerns. Parts of code have improper responsibilities either out of convenience (carelessness). Or because of over-abstracting to shoehorn different-but-similar things into a single concept (idealism). Or because of forcing conformity to my abstraction to gain the functionality (opinionated / inflexible, aka frameworky). Or coding my pre-conceived notions rather than listening to what users are telling me (hubris). I have messed up in all of these ways.
In a seeming paradox, I find Separation of Concerns is often at odds with how people normally apply the DRY (Don't Repeat Yourself) principle. Just because two pieces of code or data are similar does not mean they should be abstracted into a single thing. I always ask myself: Are these literally doing the same thing? Could they conceivably diverge in functionality? If these are the same concept, could they be two different expressions of it? (I.e. the way sales perceives a customer versus the way support does.)
I used to commonly way over-abstract things. But nowadays when it is not clear I am much more likely to duplicate first. Then wait for that day when I need to change them both in the same way for the same reason. And then apply DRY (which may just mean extracting common parts between them).
I also used to take the framework approach to hide all the details I could. Ostensibly so in the future I could just concentrate on the new requested feature, not the plumbing. But it always happened that there would be a new feature that I could not have foreseen, and the framework could not do it without a refactor. After a few rounds of this, the value of the framework approach becomes greatly diminished.
Even when you are on guard for it, some SoC violations always creep in. So it is important to refactor when they become obvious.
I think that most of the time is about that, the DRY principle wrong implemented. I work in this project, that every time that two functions share at couple of lines, they would refactor into a single one. This was a nightmare, and it only improved difficult to understand the function.
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.
There is really one overriding principle that I violated when things become messy: Separation of Concerns. Parts of code have improper responsibilities either out of convenience (carelessness). Or because of over-abstracting to shoehorn different-but-similar things into a single concept (idealism). Or because of forcing conformity to my abstraction to gain the functionality (opinionated / inflexible, aka frameworky). Or coding my pre-conceived notions rather than listening to what users are telling me (hubris). I have messed up in all of these ways.
In a seeming paradox, I find Separation of Concerns is often at odds with how people normally apply the DRY (Don't Repeat Yourself) principle. Just because two pieces of code or data are similar does not mean they should be abstracted into a single thing. I always ask myself: Are these literally doing the same thing? Could they conceivably diverge in functionality? If these are the same concept, could they be two different expressions of it? (I.e. the way sales perceives a customer versus the way support does.)
I used to commonly way over-abstract things. But nowadays when it is not clear I am much more likely to duplicate first. Then wait for that day when I need to change them both in the same way for the same reason. And then apply DRY (which may just mean extracting common parts between them).
I also used to take the framework approach to hide all the details I could. Ostensibly so in the future I could just concentrate on the new requested feature, not the plumbing. But it always happened that there would be a new feature that I could not have foreseen, and the framework could not do it without a refactor. After a few rounds of this, the value of the framework approach becomes greatly diminished.
Even when you are on guard for it, some SoC violations always creep in. So it is important to refactor when they become obvious.
I think that most of the time is about that, the DRY principle wrong implemented. I work in this project, that every time that two functions share at couple of lines, they would refactor into a single one. This was a nightmare, and it only improved difficult to understand the function.