The best programmers I know rarely see things as 100% good or bad.
The best programmers I know rarely see things as 100% good or bad.
And even if you do, it's still better to say "X is bad because Y" instead of a meaningless assertion like "X is an antipattern" or "X is a code smell".
But are the "best programmers" the best judges of such things. I often find they are not because they often understand their tools in a way that is incomprehensible to others. I've seen many junion engineers fizzle into disfunction because they are paired with "one of the best programmers". I've seen "the best programmers" adopt tools and patterns that cannot survive their departure because they are too complicated and too specialized for anyone else to own.
> rarely see things as 100% good or bad.
For me, I held this view most strongly when I was an intermediate programmer. I quickly moved into the "every tool for its job" phase after the "the things I learned with are best" phase.
But as I've become an advanced programmer, some of my opinions have become much stronger. For example (and this is just an example I don't want to argue about this) I currently see "the self initializing singleton" as pretty much a 100% bad pattern. This because my experience has taught me that not knowing when something is going to get setup is a weakness, not a virtue. This is an opinion I was actually incapable of developing as an intermediate programmer because I had not yet encountered the myriad of annoying bugs that come from ambiguities of initialization. I just respected the "ease" and "cleverness" of the pattern.
That was not the kind of developer I was thinking about.
> But as I've become an advanced programmer, some of my opinions have become much stronger
I don't mind strong opinions at all. What I mind is extremism, and how terms like antipattern and code smell contributes to it.
You called the singleton pattern you described a "pretty much 100% bad pattern", then went on to explain your experience and opinion in a humble way. I think that's a great example of a strong opinion which was not "extreme".
But that's difficult to distinguish and act upon, so the meaning seems to have morphed into generic "bad thing you should never use".
Regardless, I've never seen it refer to code that didn't turn out to be bad in the author's opinion.
- "Anti-pattern" is also ambiguous, because patterns have some bad uses, and anti-patterns have some good uses.
- And "Considered harmful" is also ambiguous. To consider something harmful is not the same as it being harmful, you're just considering it.
These phrases are used automatically and intend to sound authoritative about something being bad, period, despite their historical nuance and ambiguity. And frankly they're all disgusting and annoying at this point.
They show the author is more into clichés and clickbait, than substance.
Like, I don't think you can get away with just typing "code smell" in a CR. That's lazy but the gut reaction to some code can be a useful starting point.
I guess that is why it’s a smell and not an anti pattern, but I work in a codebase with a lot of this kinda stuff and as much as I hate the complexity required to read it, I’ve been around long enough to know why all those ifs are there and even added a few myself.
how do you feel about the code smell of a tail-recursive fizz-buzz?
Otherwise, nope, I don't care that "I checked and it's optimised correctly". We do not write optimiser dependent code in my house, write something that won't explode messily when we change target or upgrade the tools or whatever and now it stack overflows.
Kidding aside, I'm more talking about the kinds of large procedures common to C++ codebases. These involve many sequential state changes which leave lots of opportunities for not initializing things and the like when the right set of conditions are met. The more paths available through this kind of code the more likely it becomes we'll create a bad one and fail to anticipate the conditions which trigger it.