Hacker News new | ask | show | jobs
by elyseum 1893 days ago
A good example of: just because you can, it doesn’t mean you should. Yes, the if/else sequence is a bit more unstructured in terms of code layout, but chances the next developer browsing the code will instantly know what it does will be much higher.
3 comments

Spare a thought for the junior/mid-level devs who don't understand clever patterns, and the seniors who haven't read the same blog posts as the implementor of the switch(true).

Completely agree, it's like writing readable prose, understand your audience.

That said, give me proper pattern matching in JS. Hard to live with languages that haven't caught up yet.

> That said, give me proper pattern matching in JS. Hard to live with languages that haven't caught up yet.

I really want this. Along with switch being as expression. Seems like something that JavaScript is obviously missing.

> Along with switch being as expression

Even PHP has this now, albeit with a different keyword (match) due to existing switch semantics being pretty bad

I really want... switch being as expression.

Unfortunately JavaScript still hasn't caught up with CoffeeScript.

Of course, you can't evaluate prose in a REPL and see for yourself what it does.

I agree that overly clever code is always to be avoided. But is this really overly clever? I wouldn't expect an engineer early in their career necessarily to understand on sight what it does. But I might worry a little for one who couldn't figure it out through experiment.

I consider myself an advanced-beginner programmer untested in the real world (looking for my first coding job though!), and I understood it relatively quickly. It does appear more concise than many if-else statements. After the initial “what?”, I was able to quickly parse through it. I think this is faster than using the standard form.

[edit: fixed typo]

A lot of the code you're going to have to be dealing with in the wild is going to look fine, until it breaks at 2am on a Saturday and you're 3 drinks in and production is down.

You're going to hate your former cleverness then.

There should be a rule that forbids applying this reasoning to code that isn't triple-nested template SFINAE mess, or a code-generating-code-generating-code-generating-code Lisp macro.

This pattern isn't "cleverness", it's just a readability-improving trick that's cheap to figure out. The hundred seconds you spend on it seeing it for the first time is a one-time cost.

That's why I abstain when I'm oncall (or backup).

That's what the oncall bonus pay is for.

Replace alcohol with 2 hours of sleep, then :)
"faster" in which respect?
Faster to parse as a developer. I can't speak to whether computationally it is faster.

Additionally, doesn't this somewhat also bring in the methodology of dealing with the error cases first?

The only problem here is that you have to do this in the first place. This problem has been solved some 60 years ago with Lisp and `cond` construct, which is even older than `if/else if/else`! Alas, our industry likes to forget history.

That said, this isn't some kind of high-level hackery. If it's cleaner than if/else if chain, you should use it.

Programming is a profession. A professional is expected to learn and grow. The right answer to seeing a code construct one doesn't understand isn't throwing hands up in the air, but spending the few minutes necessary to figure out what it does.