Personally I like when code gets defactored*. Defactoring removes undocumented abstractions, call proxying, dynamic dispatch, higher order args, boolean args, utility source files, etc, to a
reasonable extent. Code wtfness is its total length x complexity^2 / documentation. Successful defactoring leaves you with less wtfness for a reasonable amount of time.
Re-factoring may increase (in-/en-) or decrease (de-) it. If it becomes self-opinionated, buggy and slows you down, that likely increased. Textbook refactoring usually trades amortized length for complexity, not the other way round, but that’s okay because they take it from a “completely flat code” perspective.
So it really depends on your coeffs in that formula and ideally should be managed by someone who tracks these indicators. Not by a passer-by whose taste was offended that day.
* google has some definitions, but I used the term freely
Re-factoring may increase (in-/en-) or decrease (de-) it. If it becomes self-opinionated, buggy and slows you down, that likely increased. Textbook refactoring usually trades amortized length for complexity, not the other way round, but that’s okay because they take it from a “completely flat code” perspective.
So it really depends on your coeffs in that formula and ideally should be managed by someone who tracks these indicators. Not by a passer-by whose taste was offended that day.
* google has some definitions, but I used the term freely