Speaking as someone who has written an article that had the phrase anti-pattern in the title, I would consider an anti-pattern as a practice that works initially at a small scale but doesn't scale and has no transition out of into a better pattern. For example, my article was about visual file trees and how there seems to be a low skill ceiling and alternatives that have a higher skill ceiling.
Meanwhile I believe in composition over inheritance, but inheritance is not an anti-pattern as there are some cases where it is the best tool for the job.
GOTO is another classic example of an anti-pattern. It seems to make sense in small cases where you can keep everything in your head, but as soon as you start scaling you are going to be up a creek without a paddle.
I don't think I'd disagree with any of that. The "problem" (IMHO) is that farrrrr too often, people just throw around the (lazy) term "code smell" or "anti-pattern" - without explaining what makes them "code smells" or "anti-patterns".
For example, with the GOTO thing, you could just say, dismissively, "oh... well that's an anti-pattern". Or... you could say, "that approach doesn't scale". Heck, it barely takes any more effort (syllables) to say "it doesn't scale" versus saying, "it's an anti-pattern". But it just "feels" to me like too many of our colleagues lean on the "anti-pattern" label as a way to shut down discussion.
The inheritance example is also excellent. Nearly everyone with sufficient experience has been leaning away from inheritance now for years. But "code smell" or "anti-pattern" sounds very similar to "you should never use this" - and that's just wrong. There are many caveats to using it. And there's a good chance that, given your particular situation, maybe you shouldn't use it. But there is a time-and-a-place for inheritance.
Speaking as someone who has written an article that had the phrase anti-pattern in the title, I would consider an anti-pattern as a practice that works initially at a small scale but doesn't scale and has no transition out of into a better pattern. For example, my article was about visual file trees and how there seems to be a low skill ceiling and alternatives that have a higher skill ceiling.
Meanwhile I believe in composition over inheritance, but inheritance is not an anti-pattern as there are some cases where it is the best tool for the job.
GOTO is another classic example of an anti-pattern. It seems to make sense in small cases where you can keep everything in your head, but as soon as you start scaling you are going to be up a creek without a paddle.
I don't think I'd disagree with any of that. The "problem" (IMHO) is that farrrrr too often, people just throw around the (lazy) term "code smell" or "anti-pattern" - without explaining what makes them "code smells" or "anti-patterns".
For example, with the GOTO thing, you could just say, dismissively, "oh... well that's an anti-pattern". Or... you could say, "that approach doesn't scale". Heck, it barely takes any more effort (syllables) to say "it doesn't scale" versus saying, "it's an anti-pattern". But it just "feels" to me like too many of our colleagues lean on the "anti-pattern" label as a way to shut down discussion.
The inheritance example is also excellent. Nearly everyone with sufficient experience has been leaning away from inheritance now for years. But "code smell" or "anti-pattern" sounds very similar to "you should never use this" - and that's just wrong. There are many caveats to using it. And there's a good chance that, given your particular situation, maybe you shouldn't use it. But there is a time-and-a-place for inheritance.
This reminds me of an article I read about banning the words "just" and "easy" from technical discussions.
I would probably also not use "it doesn't scale" because I usually find "scaling" is also used as techno-mumbo-jumbo to try to shut down discussions.