I agree with other's statements about not judging prematurely. I feel like every software engineer I have ever run into (including and especially myself) has done some or all of these things at one point or another. We all have bad days, we all have poor judgment sometimes. Giving people the benefit of the doubt in cases of lapsed judgment seems like it would create a far less hostile work environment. If it's systemic, it's one thing... but let's try to avoid a witch hunt mentality. Everyone's going to have off days.
The only one whose legitimacy as an antipattern I would question however would be this one:
>"Bulldozer code" that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)
I think it is useful to break up complex logic into discrete methods that represent some logical step in the overall algorithm. If they're private methods, I feel like that can add to the readability of the algorithm rather than having it be in one monolithic chunk. I've seen two camps on this - keep it inline vs. make private methods for discrete steps, and I find the latter to be more readable when I look through code (my own or someone else's).
There is a limit to that, of course. If you end up with a tangled tree of methods, that could work against readability... but even then, if you took that tangled tree and made it a single monolithic method, how often would that actually end up being more readable?
It depends. If the code doesn't not end up indented and reads like a script, I prefer to read one long method, rather than jumping around a hundred small methods and trying to keep the overall context in my head. I think this preference applies more to higher level scripting languages and not all the time.
The only one whose legitimacy as an antipattern I would question however would be this one:
>"Bulldozer code" that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)
I think it is useful to break up complex logic into discrete methods that represent some logical step in the overall algorithm. If they're private methods, I feel like that can add to the readability of the algorithm rather than having it be in one monolithic chunk. I've seen two camps on this - keep it inline vs. make private methods for discrete steps, and I find the latter to be more readable when I look through code (my own or someone else's).
There is a limit to that, of course. If you end up with a tangled tree of methods, that could work against readability... but even then, if you took that tangled tree and made it a single monolithic method, how often would that actually end up being more readable?