Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

+1 to this. Nowadays when I see some "Considered harmful" post on HN its tends to be some dude on his personal blog talking about how in his 2 years of programming experience JS framework X is bad and instead you should use JS framework Y. Instant red flag and I'm likely to ignore.


I think it's often the same with "antipattern" or "code smell".

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".


> The best programmers I know

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.


> 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.

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".


I tend to like the phrase "Strong opinions, weakly held" to describe that sort of "best programmers". Through experience they have come to hold certain ideas, and will express them strongly, but are willing to describe why, and also accept that they aren't universal, mostly rules of thumb i.e. they aren't dogmatic.


The entire concept of a "code smell" is something which is often but not always bad, so I'm not sure why rarely seeing things as 100% good or bad would lead to you avoiding the phrase.


I mean, "often, but not always bad" was what "code smell" was originally supposed to mean: Patterns which may have a valid reason, but which in the common case show some bad design or lack of understanding.

But that's difficult to distinguish and act upon, so the meaning seems to have morphed into generic "bad thing you should never use".


I think code smell has grown to have two meanings. One is a hint that something might be wrong, the other is just bad code.

Regardless, I've never seen it refer to code that didn't turn out to be bad in the author's opinion.


"Code smell" is especially ambiguous and annoying.


Intentionally ambiguous: the phrasing is specifically meant to suggest that it’s assumed non-universal and might not apply to all circumstances. If you embrace that ambiguity it’s a good antidote to the “considered harmful” problem and may well be less annoying.


- "Bad smell" immediately invokes disgusting sensory experiences. It's intended to be ambiguous but it's not used this way.

- "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.


Is it though? Like, if I see a lot of nested "ifs" with "returns" sprinkled around, I'm getting "icky" vibes way before I intellectually know what is wrong.

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 kind of feel this way sometimes, but some business or even non-business logic will require some inherent minimum amount of cyclomatic complexity. And there is only so much you can do to hide it or spread it around; depending on the specifics it may actually be better to put the whole ugliness in one place

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.


> a lot of nested "ifs" with "returns" sprinkled around

how do you feel about the code smell of a tail-recursive fizz-buzz?


If it's in a language with guaranteed tail recursion optimisation and it's idiomatic in that language (these two things often go together) then fine, seems reasonable, Go With God.

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.


Erase it and do it iteratively like any sane person!

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.


Smells like breakfast


You should write a blog about this. You could call it "Examining falsehoods programmers believe about the unreasonable effectiveness of 'considered harmful' for fun and profit."


Can it be formulated as a bunch of koans? I don't trust things that aren't.


Or: How I Learned to Stop Worrying and Love The Tropes


I completely agree. "Considered Harmful" is one of my biggest pet peeves. It irrationally irritates me.


If you love being irrationally irritated over uncreative headlines, here are a few more related contenders:

https://news.ycombinator.com/item?id=31836787

https://news.ycombinator.com/item?id=32821316


Irrational irritation considered harmful.


Harmful considerations considered harmful.


That and prefixing something -- anything! -- "unpopular opinion".


What’s better is “Mostly harmless”


When I see a "Considered Harmful" post, I still click on it, expecting to find satire since it's such a cliche at this point. I'm almost universally disappointed.


Sorry, I don’t disagree but the exact same thing goes for comments that start with ‘This!’ And ‘+1’


Yep, same here. I never read things with these sorts of titles.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: