This can also be a flag for GOOD code! I often will comment out entire class implementations of a class that’s working, but has a ton of bugs and fragilities. Then I’ll re-implement from scratch. If I totally screw things up, I’ll just uncomment.

Yes, I know my source control will keep the previous version for me, but keeping the commented code for awhile allows you to easily refer to it while implementing and debugging the replacement. The huge comment should go away after a revision or two of course.

Some problems are just complex. If a solution is hard to understand, it doesn’t necessarily mean that it’s wrong or poorly coded. It may just be a hard problem.

Also, I’m more in the “if it ain’t broke, don’t fix it” camp than the “never leave a broken window unfixed”. Key architectural code should be cleanly designed and work well. I think there needs to be a compelling case to refactor other code. Why risk introducing bugs in order to “fix” working code? Especially when the “fix” is really about making the code conform to an ideal of what good code should look like?

Unless you’re making an object library, the end user of your software will not be other programmers, and they won’t care whether you’ve used dependency injection or not, whether you’ve relied too much on a singleton, et cetera. And if you think your code will have a long shelf-life and needs to hold up to future scrutiny, you’re likely flattering yourself.

tldr